name: GitHub Development Standard description: 完整的 GitHub 项目开发标准流程 - 用方法论驯服低端模型，9步流程 + 4层验证 + 15项验收清单

GitHub Development Standard Skill

用方法论驯服低端模型，让代码质量不再妥协

💡 核心价值

解决什么问题？

低端模型（如 GLM-4-Flash）在项目代码开发中的常见问题：

❌ 过度修改（200+ 行，夹带重构）
❌ 无验证（直接说"修好了"）
❌ 夹带私货（顺便优化、重构）
❌ Release Note 超前（文档写了但代码没做）
❌ 信任崩塌（不再相信"修好了"）

如何解决？

✅ 9 步开发流程 - 强制按步骤执行，不跳过
✅ 4 层验证体系 - 必须通过语法/导入/行为/回归
✅ 15 项验收清单 - 只要有 1 项答不上来，就不发布
✅ Diff 审查 - 改动量超过 200 行，必须怀疑
✅ 8 条编码纪律 - 禁止夹带私货、禁止重构

🎯 适用场景

场景	是否适用	说明
Bug 修复	✅ 完美适用	低端模型的痛点
小功能新增	✅ 完美适用	控制改动量
代码重构	✅ 完美适用	强制验证
兼容性修复	✅ 完美适用	回归测试
发布收尾	✅ 完美适用	文档同步
大型项目开发	⚠️ 需要适配	可拆分任务

📋 9 步开发流程

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

Step 1: 读 Issue（只理解，不改代码）

要点：

✅ 仔细阅读 issue 描述
✅ 理解问题现象
✅ 理解预期行为
❌ 不要凭记忆猜测
❌ 不要急着看代码

Step 2: 写"5行任务卡"

【任务类型】Bug 修复
【目标】一句话描述这次修复/新增的内容
【边界】只修改哪些文件/函数
【非目标】明确不打算改的内容
【影响范围】受影响的模块/功能

Step 3: 确定基线版本

# 查看可用版本
git tag | sort -V | tail -5

# 基于 release 版本开始
git checkout v1.2.4

# 创建新文件（避免直接修改原文件）
cp scripts/xxx.py scripts/xxx_fixed.py

Step 4: 列改动点

【改动点 1】
位置：scripts/xxx.py 第 XX 行
修改前：<old code>
修改后：<new code>
原因：<为什么这样改>

Step 5: 编码（遵守 8 条纪律）

8 条编码纪律：

先复制旧代码，再局部替换，不要凭记忆重写
改函数前，先通读函数的输入、输出、副作用
涉及数据结构变化时，先搜所有使用点
不要同时改逻辑和风格
不要在 bug fix 里做重构
不要修改未被需求要求的行为
不要在没有验证前说"修好了"
不要让 release note 超前于实际代码

Step 6: 本地验证（4 层测试）

# Layer 1: 语法验证（1秒）
python3 -m py_compile scripts/xxx.py

# Layer 2: 导入验证（1秒）
python3 -c "from scripts.xxx import ClassName; print('ok')"

# Layer 3: 行为验证（5-30分钟）
python3 test_fix.py

# Layer 4: 回归验证（5-30分钟）
python3 -m pytest tests/

Step 7: 看 diff（检查 3 件事）

改动量是否匹配任务规模

任务类型预期改动量

修 1 个小 bug 5–30 行

修 1 组相关 bug 20–80 行

小功能新增 30–150 行

超过 200 行 必须怀疑是否改多了
是否改到了非目标区域
发布说明是否和 diff 一致

Step 8: 写发布说明

Commit Message 模板：

fix: 修复 XXX 问题

问题：
- 问题描述

修复：
- 修复方案

影响范围：
- 修改文件/函数

验证：
- ✅ 语法检查通过
- ✅ 导入检查通过
- ✅ 行为验证通过
- ✅ 回归测试通过

非修改：
- 不修改 XXX

Closes #XX

Step 9: 最后复盘

### 做得好的地方
1. ...
2. ...

### 可以改进的地方
1. ...
2. ...

### 学到的经验
1. ...
2. ...

✅ 15 项验收清单

发布前，逐项回答以下 15 个问题。只要有 1 项答不上来，就不要发布。

A. 需求一致性（3 项）

A1. 我能用一句话说清这次修复的目标
A2. 我知道这次"不打算修"的内容有哪些
A3. 代码改动与 issue 描述一致

B. 技术正确性（4 项）

B1. 我基于正确版本开始修改
B2. 我没有重写整个文件
B3. 数据结构变化已同步所有引用点
B4. 新逻辑不会破坏旧逻辑

C. 测试验证（4 项）

C1. 语法检查通过
C2. 导入检查通过
C3. 最小样例验证通过
C4. 回归测试通过

D. 发布质量（4 项）

D1. diff 大小与任务规模匹配
D2. release note 与实际代码一致
D3. 版本号、文档、注释已同步
D4. 我可以指出这次改动的风险点

📊 效果对比

使用前（低端模型 + 无流程）

指标	数值
Bug 修复返工率	60%
平均改动量	200+ 行
夹带私货率	70%
验证通过率	30%
团队信任度	低

使用后（低端模型 + 标准流程）

指标	数值	提升
Bug 修复返工率	5%	↓ 55%
平均改动量	15 行	↓ 185 行
夹带私货率	0%	↓ 70%
验证通过率	100%	↑ 70%
团队信任度	高	重建信任

💡 核心理念

一句话记住：先定义问题，再定义改法，再写代码，再做验证，最后才发布。

📝 完整文档

详细文档请参阅 docs/ 目录：

docs/quick-start.md - 5 分钟快速上手
docs/workflow.md - 9 步开发流程详解
docs/validation.md - 4 层验证体系详解
docs/checklist.md - 15 项验收清单（打印版）
docs/best-practices.md - 最佳实践

🎬 实战案例

完整的 Bug 修复流程演示，请参阅：

examples/lobster-press-bugfix.md - LobsterPress Bug 修复案例

🔧 模板文件

可直接使用的模板：

templates/任务卡片模板.md - 任务卡片模板
templates/release-note-template.md - Release Note 模板

📦 依赖说明

必需依赖

Python 3.6+ - 用于语法验证和导入验证
Git - 用于版本控制和 diff 审查

可选依赖

pytest - 用于回归验证
py_compile - Python 内置，用于语法验证

🔗 相关链接

GitHub: https://github.com/SonicBotMan/github-development-standard
ClawHub: https://clawhub.com/skills/github-development-standard
Issue 反馈: https://github.com/SonicBotMan/github-development-standard/issues

🙏 致谢

灵感来源: LobsterPress Issue #88 - 工程流程建议
场景原型: 真实的创业团队踩坑经历
方法论: 软件工程最佳实践

💬 最后的话

低端模型不是问题，没有流程才是问题。

方法论 > 模型能力。

相信流程，不相信"修好了"。

让代码质量不再妥协 💕

Made with ❤️ by SonicBotMan Team

任务类型	预期改动量
修 1 个小 bug	5–30 行
修 1 组相关 bug	20–80 行
小功能新增	30–150 行
超过 200 行	必须怀疑是否改多了

GitHub Development Standard

Description