AI 软件开发培训
第 1 部分 – Harness 工程基础
您将学习：
- 为什么给 AI 编辑器当保姆无法扩展
- Harness 工程：人类掌舵，代理执行
- 使用 CodeFactory CLI 引导一个仓库
- 检测技术栈、风险分级和架构边界
- 将 CLAUDE.md 编写为代理的控制平面
- 将 prompt 和 guard 作为代码进行版本化
- Pre-commit 钩子、风险策略门和受保护文件
第 2 部分 – GitHub Actions 中的自动化开发
您将学习：
- Issue triage、planner 和 implementer 代理
- 具有结构化裁决的只读 review 代理
- 修复循环和受保护文件的自动回滚
- 具有 SHA 纪律的风险门控 CI 流水线
- Doc gardening 和每周 harness 指标
- 实时运行完整的 issue → PR → merge 循环
- 将 harness 适配到你自己的代码库
展示你的专业技能获取我们的证书！
停止给 AI 编辑器当保姆
今天大多数开发者都在用错误的方式使用 AI。他们坐在 Cursor 或 Copilot Chat 前，接受一个建议，滚动，接受另一个，撤销，重试，把错误粘贴回聊天窗口，然后收工。感觉很有生产力，但这其实是穿着 AI 外衣的手工劳动。人类仍然是瓶颈。代理仍然在猜测。没有任何东西是可重复的，没有任何东西是可审查的，也没有任何东西能扩展到一个开发者和一个分支之外。
这次培训颠倒了这个模型。你的团队将学会把 AI 编码移出编辑器，进入 GitHub Actions，代理在临时 runner 中运行，由版本化的 prompt 和自动化质量门守护。开发者打开一个 issue，审查一个 pull request 并点击 merge。中间的所有事情——triage、规划、实现、代码审查、修复——都在普通 CI 基础设施上自动进行。
CodeFactory harness 工具包
我们在 CodeFactory
之上进行教学，这是一个开源 CLI，可将完整的代理安全 harness 引导到任何现有仓库中。一个命令——codefactory init——你的仓库就能获得 16 个 harness 和 14+ 个针对你的技术栈量身定制的 GitHub Actions 工作流：
- 一个风险契约（
harness.config.json），将每个文件分类为 Tier 1、2 或 3，并强制执行适当的审查级别 - 代理指令（
CLAUDE.md），描述约定、依赖规则和受保护文件 - 一个 issue triage 代理，在编写任何代码之前评估清晰度、可重现性和范围
- 一个 issue planner，以只读方式读取代码库并发布一个结构化的实现计划
- 一个 issue implementer，创建分支，实现更改，运行基线验证并打开一个 PR
- 一个 review 代理，使用只读工具运行，并发出由第二个轻量级模型分类的 APPROVE / REQUEST_CHANGES / COMMENT 裁决
- 一个修复循环，将 review 裁决反馈给 implementer，最多三次自动修复循环，然后升级给人类
- Doc gardening、结构测试、harness 冒烟测试和每周指标工作流，保持 harness 本身的健康
一切都在仓库中。没有外部仪表板，没有供应商锁定，没有隐藏状态。编辑一个 prompt 就是一个普通的 pull request。
真实生产示例：sport-affiliate
我们会带你走过 QualityUnit/sport-affiliate ，一个运行完整 CodeFactory harness 的真实生产 monorepo（三个 Next.js 站点、一个共享引擎和一个 Python 数据管道）。你将阅读驱动它的实际工作流文件、prompt 和 guard 脚本：
- 15 个 GitHub Actions 工作流编排完整的 issue → PR → merge 循环
.codefactory/prompts/中的四个定制化 prompt（issue-triage.md、issue-planner.md、issue-implementer.md、review-agent.md）- TypeScript guard 脚本（
scripts/*-guard.ts），在每次代理运行前进行 pre-flight 检查，并决定它是否应该启动 - 四阶段 fail-fast CI 流水线，跳过完整的 Next.js 构建（每个 25 分钟），转而使用 type-check + lint + 结构测试
- SHA 纪律：每个下游作业都检出风险门报告的确切 SHA，这样代理就无法在流水线中途 race-push
- 受保护文件（
.github/workflows/*、harness.config.json、CLAUDE.md、lock 文件、部署配置），如果代理触碰它们会被自动回滚 - review prompt 从
origin/main加载——而不是 PR 分支——这样代理编写的 PR 就无法篡改自己的 reviewer
端到端的开发者体验如下：一个人打开一个 issue。triage 代理给它打标签，必要时提出澄清问题，然后交给 planner。planner 将实现计划作为评论发布。implementer 创建 issue-N，实现更改，运行质量门并打开一个 PR。review 代理进行审查。如果请求更改，implementer 会以 review-fix 模式再次被 dispatch——最多三个循环——然后升级给人类。唯一的人类触点是打开 issue 和批准最终的 merge。
你的团队将带回什么
在培训结束时，你的开发者将能够在自己的仓库中引导完全相同的设置，编写和调整他们自己的代理 prompt，定义匹配其架构的风险分级，并通过 Mean-Time-To-Harness 和 SLO 指标衡量 harness 是否真正起作用。他们将带着一个在你的真实仓库之一上运行的 harness 离开——而不是一个玩具示例。
