STEP 01 ／ 06
从一个
Issue 开始.
用一两句话把『为谁解决什么』写清楚——能讲明白的需求，才值得进入下一步。Issue 是这次工作的起点，也会是它的归档。
ISSUE · Frame the problem.
人思考，AI 执行， 人验收.
一份公开的 operating log —— 六步 workflow、真实事故 case、可装 Skill。给所有想看 AI-native 团队怎么工作的人。
GitHire 是一套 AI-native 工程方法论——把 "人思考、AI 执行、人验收" 写成可复用的六步 workflow，拿真实事故 case 验证它，再用 Skill 让任何 agent 装上。
- Issue-first
- 所有任务从一个能讲明白的 Issue 起步，需求即文档。需求里每一处空白，都是 AI 的自由发挥空间。
- Human-orchestrated
- AI 在沙盒里完成实现、起 PR、互审；人保留 framing、架构方向与合并决定权。AI 在执行，人在判断。
- Production-bound
- 终点是合并进主分支的 PR，不是 demo、不是练习题。可复用的 Skill 与决策记录回写到 Issue，留作下一次的起点。
从一个
STEP 02 ／ 06
进入开发
沙盒.
沙盒是长期运行的开发环境，保留依赖、缓存与既有数据，让 AI 能在真实的上下文里工作，而不是一次性容器。
SANDBOX · A persistent dev environment.
STEP 03 ／ 06
执行任务
发起 PR.
把 Issue 交给 Claude Code 或 Codex，由它在沙盒里完成实现：写代码、跑测试、迭代修复，最终发起一份 PR。
EXECUTE · Claude Code or Codex.
STEP 04 ／ 06
另一位 AI
审核 PR.
这一步交给另一位 Claude Code 或 Codex。它读完整份 PR，结合 CI 与静态检查，给出可执行的修改意见——双 AI 互审。
AI REVIEW · Two agents, one PR.
STEP 05 ／ 06 · 关键一步
人类
架构师 评审.
整条流程的核心。由人类架构师判断这次改动是否符合系统方向、是否引入隐性债务、是否值得上线。AI 提供线索，决定权在人。
ARCHITECT · Where humans decide.
STEP 06 ／ 06
合并
并 上线.
架构师签字之后，PR 合入主干、部署到生产。可复用的 Skill、Checklist、评审记录回写到 Issue，留作下一次的起点。
PRODUCTION · Ship it.
Issue · Sandbox · AI · 架构师 · 上线
—— 交付一次完整的改动.
- 01 Issue
- 02 Sandbox
- 03 PR
- 04 AI Review
- 05 Architect
- 06 Production
六步串成一条流水线 · 从需求到上线 · 每一次都把决定与产物回写到 Issue
流水线之外，
那些让协作成立的小习惯.
流程负责"做什么"，习惯负责"在什么节奏里做"。下面这四件事，是我们用来让 AI-native 协作真正运转起来的最小集。
-
RITUAL
一日的形状
THE SHAPE OF A DAY
每天早晨花一分钟，写下今天最重要的那个 Issue。它不是任务清单，而是这一天的锚点——所有的对话、改动、PR，都围绕它发生。
- MORNING
- 写下 #today —— 当日最重要的 Issue
- DURING
- 所有改动都挂在这条 Issue 下面
- EVENING
- 用一句话回写今天的进展或决定
-
RITUAL
架构师与开发者
ARCHITECT & DEVELOPERS
架构师拥有方向上的最终决策权；开发者围绕 Issue 进行开发，通过 Issue 与 PR 与架构师对话。评审与决策落在 GitHub 上，飞书留给当下需要立刻对齐的事。
- ARCHITECT
- 方向与边界的最终决策权
- DEVELOPER
- 围绕 Issue 开发 · 在 PR 中对话
- CHANNEL
- 评审在 GitHub · 即时同步在飞书
-
RITUAL
Issue 与 PR 的追踪
EVERY ISSUE IS TRACKED
每一个 Issue 都有一条对应的 PR 来追踪它的执行过程，PR 上的评论会被完整保留下来——下一个接手的人，可以从 Issue 一路读到当时是怎么决定的。
- LINK
- 每个 Issue 对应一条 PR · 一一映射
- KEEP
- PR 评论作为决策记录长期保留
- READ
- 新成员从 Issue → PR 还原历史
-
RITUAL
从 Prompt 到 Skill
FROM PROMPT TO SKILL
一段反复用过、值得记住的 prompt，就值得变成 Skill —— 带名字、带说明、任何 agent 都能装上调用。这是团队最值得沉淀的工件。
- SKILL
- GitHire · 六步 workflow
- SPEC
- Prompt Spec · 六段式 issue 模板
- USE
- npx skills add realRoc/skills
AI 写得快，
不等于人想得清.
下面是最容易被跳过的问题——也是 GitHire 真正想回答的。
AI 写代码这么快，为什么还要 6 步？
因为速度不是问题——AI 5 分钟写完的代码，人 review 需要 30 分钟才能识别"路径不对"。6 步 workflow 不是给 AI 装护栏，是给人类留决策点：Issue 是 framing 的决策点，架构师评审是方向的决策点，sandbox 与 AI review 是两次"还来得及反悔"的决策点。一旦决策点形同虚设，AI 的速度就会变成事故的速度。看一次跳过决策点的代价 →
Architect 30 秒就能识别问题，AI review 5 分钟都识别不出来吗？
两者识别的是不同维度。AI review 看的是"代码自带的上下文"——PR 内部一致性、edge cases、命名一致性、被忽略的 nullability；架构师看的是"系统侧才有的上下文"——QPS 曲线、历史事故、容量规划。互补，不重叠。Case 01 里那 22 行 SCAN 代码在 AI review 看来完全正确，但架构师 30 秒就能看出"这个 endpoint 每次请求都扫全表"是不可接受的。
一份好的 Issue 长什么样？
六段。Goal 说清楚要解决什么；Constraints 说清楚不能动什么；Non-goals 说清楚不做什么；Verification 说清楚怎么证明成功；Architecture notes 说清楚系统边界；Existing context 说清楚已有实现。缺一段，AI 就会在那一段自由发挥。具体对照请看 case 01 里同一需求的 BAD vs GOOD →。
AI 出事故，谁来背锅？
架构师。AI 不背锅——背锅意味着代理责任，AI 没有代理资格。所有合入主干的代码都有一位架构师签字，签字就是认领系统侧后果。GitHire 不允许 review 责任被"AI 评过了"稀释——AI review 是辅助证据，架构师 review 是决定。
Conceptual integrity 怎么在 AI 协作下保持？
通过显式的架构 owner。AI agent 可以生成 PR，但 Architect 这一步由人类负责。所有 PR 必须能被一位 architect 用一句话讲清楚动机和取舍——做不到的 PR 不 merge。这条约束让概念一致性不被并发的 agent 数量稀释。
Sandbox 里写的代码为什么默认不进主分支？
因为第一版的价值是澄清问题，不是交付。GitHire 把 Brooks 那句 "Plan to throw one away; you will, anyhow" 显式化：sandbox 阶段的代码默认不进主干，存在的目的是验证方向、暴露未知。等真正写主干代码时，问题已经清楚，AI 才有可能一次写对。
进度落后的团队是否需要再加人？
这个问题的经典版本来自 Brooks 的 Mythical Man-Month：给延期项目加人,会让项目更延期——因为新人需要学习上下文,沟通成本随人数二次方上升,短期内整体进度反而更慢。放到 AI-native 团队里,这条规律没失效,只是稀缺品换了：coding 手脚不缺——AI 已经够快——稀缺的是会 frame issue、做架构判断的脑子。一个能写出 6 段式 issue 的人可以同时 orchestrate 几个 agent；多请一个 coder 反而稀释了方向。加人之前先问：是 framing 不够，还是吞吐不够？
『人月』是个伪命题吗？
"人月"是软件项目的传统估算单位——"这个功能要花 6 个人月"。Brooks 早就指出这是粗糙的近似：人和月不能线性互换,加一倍人不会让项目快一倍。放到 AI-native 团队里,人月不只是粗糙,而是失效：它建模的是 coding 工作量,但 coding 已经不是瓶颈——AI agent 5 分钟交付过去一个人月的代码量；而一条糟糕的 issue 让 AI 跑出 22 行 SCAN（case 01）,损失 25 小时救火,这部分根本无法用人月度量。新的单位应该是"决策点节奏"：每周完成多少次 framing、多少次架构评审、多少次 sandbox → PR 闭环。
Deadline 为什么总是骗人的？
软件项目几乎从不按时交付——经典的解释是：估算在信息最少的时候做出,承诺在压力最大的时候许下,两边都不靠谱。放到 AI-native 团队里,deadline 仍然不准,但失准的根源换了：过去 deadline 滑掉是因为 coding 慢；现在 coding 不慢了,deadline 滑掉是因为 framing 失误 和 review 来不及——一条没写清的 issue 让 AI 走错方向 20 分钟,代价是 25 小时根治（case 01）。GitHire 不承诺 deadline,改承诺"决策点完成度"：issue framing 完成 / architect 签字完成 / sandbox 验证完成。可观测的状态替代主观时间,越接近交付,预测越收敛。
AI 在执行，
人 在 frame 与判断.
Stop assisting. Start operating.