Github Dev Standard Free

个人开发者项目开发标准流程，含 9 步开发流程与基础验收清单。

项目开发标准（免费版）

概述

本工具为独立开发者提供结构化的项目开发标准流程，解决开发中常见的过度修改、无验证、夹带重构等问题。通过 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中声明的使用场景,均已在上述能力点中提供对应的操作支持。

使用场景

场景一：缺陷修复标准化

开发者收到一个缺陷报告，需要按标准流程修复。

text

用户：收到一个支付金额计算错误的缺陷，帮我按标准流程修复

助手：按 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. 提交并发布

场景二：功能开发流程管控

开发者需要新增一个用户注册功能，需要控制改动范围。

text

用户：要新增用户注册功能，怎么按标准流程来

助手：
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 和参数说明

场景三：提交前自查

开发者完成编码后，提交前进行质量自查。

bash

# 执行 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 步开发流程

text

1. 读 issue → 2. 写任务卡 → 3. 确定基线
     ↓
4. 列改动点 → 5. 编码 → 6. 本地验证
     ↓
7. 看 diff → 8. 写发布说明 → 9. 复盘

8 条编码纪律

序号	纪律	说明
1	先复制旧代码，再局部替换	避免重写整个文件
2	改函数前，先通读输入/输出/副作用	理解后再修改
3	涉及数据结构变化时，先搜所有使用点	避免遗漏引用
4	不要同时改逻辑和风格	保持改动单一
5	不要在缺陷修复里做重构	分离关注点
6	不要修改未被需求要求的行为	控制影响范围
7	不要在验证前说"修好了"	先验证再结论
8	不要让 release note 超前于实际代码	文档与代码同步

4 层验证

bash

# 第一层：语法检查
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

示例

任务卡模板

markdown

## 任务卡

**目标**：一句话描述本次修复/开发目标
**基线版本**：基于哪个分支/提交开始
**改动范围**：
- 修改文件列表
- 新增文件列表

**不修改的内容**：
- 明确列出不在本次范围内的内容

**验证方式**：
- 语法检查命令
- 测试命令

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	可以指出这次改动的风险点

最佳实践

1. 先写任务卡再编码：明确目标和范围后再动手

2. 改动量与任务匹配：缺陷修复控制在 15 行以内

   bash

   git diff --stat
   

3. 分离逻辑与风格：不要在同一提交中混合

4. 验证先于结论：所有"修好了"必须有验证证据

5. diff 审查：提交前务必检查改动内容

   bash

   git diff
   git diff --staged
   

6. 使用工具验证：工具验证比人工更可靠

   bash

   grep -r "oldFunctionName" src/  # 搜索所有使用点
   

常见问题

Q1：改动量总是超标怎么办？

text

可能原因：
1. 需求理解不清晰，范围蔓延
2. 顺手做了重构
3. 基线版本不对

解决方案：
1. 重新写任务卡，明确"不修改"的边界
2. 将重构拆分为独立提交
3. 确认基线版本后再开始

Q2：如何避免夹带重构？

text

1. 编码前列出所有改动点
2. 编码时只做列出的改动
3. 提交前用 git diff 逐行审查
4. 发现夹带的改动，撤销或拆分到独立提交

Q3：没有测试用例怎么验证？

bash

# 最小验证：语法 + 导入
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：多文件修改如何确保同步？

bash

# 搜索所有使用点
grep -r "OldClassName" src/
grep -r "old_function_name" src/

# 确认所有引用都已更新
grep -r "NewClassName" src/

Q5：release note 怎么写？

markdown

## v1.2.1

### 修复
- 修复支付金额计算精度丢失问题（calc.js）
- 修复登录页面在 Safari 下的样式错位（login.css）

### 说明
- 本次改动 12 行，涉及 2 个文件
- 已通过语法检查和回归测试

Q6：如何控制 AI 辅助编码的改动量？

text

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环境不可用
• 复杂业务场景建议结合人工经验判断
• 执行效率受模型能力与网络环境影响
• 当前为免费版本,如需完整功能请升级到付费版获取全部能力