项目开发标准（免费版）
概述
本工具为独立开发者提供结构化的项目开发标准流程，解决开发中常见的过度修改、无验证、夹带重构等问题。通过 9 步开发流程、8 条编码纪律、4 层验证机制和 15 项验收清单，帮助开发者建立"先定义问题、再定义改法、再写代码、再做验证、最后才发布"的工程习惯。免费版聚焦个人开发场景，提供开箱即用的流程模板与检查清单。
核心能力
| 能力模块 | 描述 | 解决的问题 |
|---|---|---|
| 9 步开发流程 | 从需求到发布的完整流程 | 流程缺失导致返工 |
| 8 条编码纪律 | 约束修改范围与行为 | 过度修改、夹带重构 |
| 4 层验证 | 语法→导入→样例→测试 | 无验证直接发布 |
| 15 项验收清单 | 交付前的多维度检查 | 质量标准不统一 |
技术实现要点：核心能力基于input_params参数与output_format配置实现,支持创建/查询/修改/删除等操作模式,通过config_options进行运行时配置。 |
核心功能执行
用input_params参数进行配置。
输入: 用户提供核心功能执行所需的指令和必要参数。 处理: 按照skill规范执行核心功能执行操作,遵循单一意图原则。 输出: 返回核心功能执行的执行结果,包含操作状态和输出数据。
- 执行此能力时使用
input_params参数,支持创建/查询/导出操作
参数配置与调用
用config_options参数进行配置。
输入: 用户提供参数配置与调用所需的指令和必要参数。 处理: 按照skill规范执行参数配置与调用操作,遵循单一意图原则。 输出: 返回参数配置与调用的执行结果,包含操作状态和输出数据。
- 执行此能力时使用
config_options参数,支持修改/重置/导入操作
结果处理与输出
用output_format参数进行配置。
输入: 用户提供结果处理与输出所需的指令和必要参数。 处理: 按照skill规范执行结果处理与输出操作,遵循单一意图原则。 输出: 返回结果处理与输出的执行结果,包含操作状态和输出数据。
- 执行此能力时使用
output_format参数,支持导出/保存/转换操作 能力覆盖范围：本skill的核心能力覆盖以下场景关键词：个人开发者项目开、发标准流程、步开发流程与基础、面向独立开发者的、项目开发标准化工、通过结构化流程约、束代码质量、读需求、写任务卡、条编码纪律防止过、层基础验证、项验收清单确保交、付质量等。这些关键词对应description中声明的使用场景,均已在上述能力点中提供对应的操作支持。
使用场景
场景一：缺陷修复标准化
开发者收到一个缺陷报告，需要按标准流程修复。
用户：收到一个支付金额计算错误的缺陷，帮我按标准流程修复
助手：按 9 步流程执行
1. 读 issue：理解缺陷描述，明确"支付金额多算了一分钱"
2. 写任务卡：
- 目标：修复支付金额计算精度问题
- 不修改：支付流程逻辑、UI 交互
- 基线版本：当前 main 分支
3. 列改动点：
- src/utils/calc.js 的 toFloat 函数
- 仅修改浮点转整数逻辑
4. 编码：局部替换，不重写整个文件
5. 本地验证：
node -c src/utils/calc.js # 语法检查
node -e "require('./src/utils/calc.js')" # 导入检查
node test-calc-fix.js # 样例验证
npm test # 回归测试
6. 看 diff：确认改动量在 15 行以内
7. 写发布说明：明确修复内容和影响范围
8. 提交并发布
场景二：功能开发流程管控
开发者需要新增一个用户注册功能，需要控制改动范围。
用户：要新增用户注册功能，怎么按标准流程来
助手：
1. 读需求：用户注册功能，包含邮箱注册和手机号注册
2. 写任务卡：
- 目标：实现用户注册 API
- 范围：仅后端 API，不含前端页面
- 不修改：现有登录逻辑
3. 确定基线：基于 main 分支创建 feature/register
4. 列改动点：
- 新增 src/controllers/register.js
- 修改 src/routes/index.js（仅添加路由）
- 新增 src/validators/register.js
5. 编码：先复制相似代码结构，再局部修改
6. 验证：
npm run lint # 代码规范
npm test # 单元测试
npm run test:e2e # 集成测试
7. 检查 diff：确认没有夹带重构
8. 发布说明：列出新增 API 和参数说明
场景三：提交前自查
开发者完成编码后，提交前进行质量自查。
# 执行 15 项验收清单自查
# A. 需求一致性
echo "A1. 能用一句话说清这次修复的目标？ [y/n]"
echo "A2. 知道这次不打算修的内容有哪些？ [y/n]"
echo "A3. 代码改动与需求描述一致？ [y/n]"
# B. 技术正确性
echo "B1. 基于正确版本开始修改？ [y/n]"
echo "B2. 没有重写整个文件？ [y/n]"
echo "B3. 数据结构变化已同步所有引用？ [y/n]"
echo "B4. 新逻辑不会破坏旧逻辑？ [y/n]"
# C. 测试验证
python3 -m py_compile scripts/xxx.py # C1. 语法检查
python3 -c "from scripts.xxx import ClassName" # C2. 导入检查
python3 test_fix.py # C3. 样例验证
python3 -m pytest tests/ # C4. 回归测试
# D. 发布质量
git diff --stat # D1. 确认 diff 大小与任务规模匹配
不适用场景
以下场景项目开发标准免费版不适合处理：
- 无明确技术栈的模糊需求
- 纯架构设计决策
- 运维部署管理
触发条件
需要代码生成、编程辅助、调试测试、开发部署时使用。不适用于非本工具能力范围的需求。
快速开始
9 步开发流程
1. 读 issue → 2. 写任务卡 → 3. 确定基线
↓
4. 列改动点 → 5. 编码 → 6. 本地验证
↓
7. 看 diff → 8. 写发布说明 → 9. 复盘
8 条编码纪律
| 序号 | 纪律 | 说明 |
|---|---|---|
| 1 | 先复制旧代码，再局部替换 | 避免重写整个文件 |
| 2 | 改函数前，先通读输入/输出/副作用 | 理解后再修改 |
| 3 | 涉及数据结构变化时，先搜所有使用点 | 避免遗漏引用 |
| 4 | 不要同时改逻辑和风格 | 保持改动单一 |
| 5 | 不要在缺陷修复里做重构 | 分离关注点 |
| 6 | 不要修改未被需求要求的行为 | 控制影响范围 |
| 7 | 不要在验证前说"修好了" | 先验证再结论 |
| 8 | 不要让 release note 超前于实际代码 | 文档与代码同步 |
4 层验证
# 第一层：语法检查
python3 -m py_compile scripts/xxx.py
# 或
node -c src/xxx.js
# 第二层：导入检查
python3 -c "from scripts.xxx import ClassName"
# 或
node -e "require('./src/xxx.js')"
# 第三层：最小样例验证
python3 test_fix.py
# 或
node test-fix.js
# 第四层：回归测试
python3 -m pytest tests/
# 或
npm test
示例
任务卡模板
## 任务卡
**目标**：一句话描述本次修复/开发目标
**基线版本**：基于哪个分支/提交开始
**改动范围**：
- 修改文件列表
- 新增文件列表
**不修改的内容**：
- 明确列出不在本次范围内的内容
**验证方式**：
- 语法检查命令
- 测试命令
15 项验收清单
A. 需求一致性（3 项）
| 编号 | 检查项 |
|---|---|
| A1 | 能用一句话说清这次修复的目标 |
| A2 | 知道这次"不打算修"的内容有哪些 |
| A3 | 代码改动与需求描述一致 |
B. 技术正确性（4 项）
| 编号 | 检查项 |
|---|---|
| B1 | 基于正确版本开始修改 |
| B2 | 没有重写整个文件 |
| B3 | 数据结构变化已同步所有引用点 |
| B4 | 新逻辑不会破坏旧逻辑 |
C. 测试验证（4 项）
| 编号 | 检查项 |
|---|---|
| C1 | 语法检查通过 |
| C2 | 导入检查通过 |
| C3 | 最小样例验证通过 |
| C4 | 回归测试通过 |
D. 发布质量（4 项）
| 编号 | 检查项 |
|---|---|
| D1 | diff 大小与任务规模匹配 |
| D2 | release note 与实际代码一致 |
| D3 | 版本号、文档、注释已同步 |
| D4 | 可以指出这次改动的风险点 |
最佳实践
-
先写任务卡再编码：明确目标和范围后再动手
-
改动量与任务匹配：缺陷修复控制在 15 行以内
git diff --stat -
分离逻辑与风格：不要在同一提交中混合
-
验证先于结论：所有"修好了"必须有验证证据
-
diff 审查：提交前务必检查改动内容
git diff git diff --staged -
使用工具验证：工具验证比人工更可靠
grep -r "oldFunctionName" src/ # 搜索所有使用点
常见问题
Q1：改动量总是超标怎么办？
可能原因：
1. 需求理解不清晰，范围蔓延
2. 顺手做了重构
3. 基线版本不对
解决方案：
1. 重新写任务卡，明确"不修改"的边界
2. 将重构拆分为独立提交
3. 确认基线版本后再开始
Q2：如何避免夹带重构？
1. 编码前列出所有改动点
2. 编码时只做列出的改动
3. 提交前用 git diff 逐行审查
4. 发现夹带的改动，撤销或拆分到独立提交
Q3：没有测试用例怎么验证？
# 最小验证：语法 + 导入
python3 -m py_compile your_script.py
python3 -c "import your_module"
# 手动样例验证
python3 -c "
from your_module import your_function
result = your_function(test_input)
assert result == expected, f'Expected {expected}, got {result}'
print('验证通过')
"
Q4：多文件修改如何确保同步？
# 搜索所有使用点
grep -r "OldClassName" src/
grep -r "old_function_name" src/
# 确认所有引用都已更新
grep -r "NewClassName" src/
Q5：release note 怎么写？
## v1.2.1
### 修复
- 修复支付金额计算精度丢失问题（calc.js）
- 修复登录页面在 Safari 下的样式错位（login.css）
### 说明
- 本次改动 12 行，涉及 2 个文件
- 已通过语法检查和回归测试
Q6：如何控制 AI 辅助编码的改动量？
1. 明确告诉 AI：只修改指定文件的指定函数
2. 提供任务卡作为上下文
3. 要求 AI 输出 diff 而非完整文件
4. 逐行审查 AI 生成的代码
5. 拒绝任何超出范围的"优化建议"
依赖说明
运行环境
- Agent 平台: 支持读取 SKILL.md 的任意 AI Agent（Claude Code / Cursor / Codex / Gemini CLI 等）
- 操作系统: Windows / macOS / Linux
依赖详情
| 依赖项 | 类型 | 是否必需 | 获取方式 |
|---|---|---|---|
| Python | 运行时 | 可选 | python.org 下载 |
| Node.js | 运行时 | 可选 | nodejs.org 下载 |
| Git | 命令行工具 | 推荐 | 系统包管理器安装 |
| LLM API | API | 必需 | 由 Agent 内置 LLM 提供 |
API Key 配置
- 本工具为纯 Markdown 指令驱动，无需额外 API Key
- 如需操作 GitHub Issue，需要配置 GitHub CLI 令牌
可用性分类
- 分类: MD+EXEC（Markdown 指令 + 命令行执行）
- 说明: 通过自然语言指令驱动 Agent 执行开发流程，验证步骤需要命令行执行能力
错误处理
| 错误场景 | 原因 | 处理方式 |
|---|---|---|
| 配置错误 | 参数缺失或格式错误 | 检查依赖说明中的配置要求 |
| 运行时错误 | 运行环境不满足 | 确认运行环境符合依赖说明 |
| 网络错误 | 连接超时或不可达 | 执行ping命令测试网络连通性,检查防火墙和代理设置连接后执行ping命令测试网络连通性,检查防火墙和代理设置连接后重新执行命令，参考国内替代方案 |
已知限制
- 需LLM支持,无LLM环境不可用
- 复杂业务场景建议结合人工经验判断
- 执行效率受模型能力与网络环境影响
- 当前为免费版本,如需完整功能请升级到付费版获取全部能力
评论
加载中…