diff --git a/2Areas/AI工作流/人类注意力应分配到高杠杆的点.md b/2Areas/AI工作流/人类注意力应分配到高杠杆的点.md index a999bb2..a0831ca 100644 --- a/2Areas/AI工作流/人类注意力应分配到高杠杆的点.md +++ b/2Areas/AI工作流/人类注意力应分配到高杠杆的点.md @@ -1,11 +1,31 @@ ## 参考资料 - [[清华大学 驾驭工程 Harness Engineering 研究报告]] - - openAI对于agent开发的建议 + - OpenAI 对 Agent 开发的建议 -## Why？ -- AI Agent产出的代码量太大，人类的注意力已经不能像过去那样逐行代码review，产出速率收到人类review的限制 +## 核心判断 +- AI Agent 的代码产出速度，已经远远超过人类逐行 review 的速度。 +- 因此，人类注意力不应该继续主要投入在“低杠杆的代码逐行检查”上，而应该转向“高杠杆的约束与表达”。 +- 真正限制系统质量的，往往不是 Agent 写代码的速度，而是需求边界、架构约束、接口契约和验收标准是否足够清晰。 -## How? -- SVG图 -- c4-dynamic文档 -- flow文档 \ No newline at end of file +## 人类应该重点投入的高杠杆点 +- 目标与边界 + - 先定义要解决什么、不解决什么、什么算完成。 +- 架构与模块划分 + - 提前收敛模块边界、职责分工、依赖方向，避免 Agent 在实现期自由发散。 +- 接口契约 + - 明确输入、输出、异常、状态变化，让实现与 review 都有统一基准。 +- 关键流程表达 + - 用图和结构化文档表达核心链路，比直接 review 大量代码更省注意力。 +- 验收标准 + - 提前定义“什么结果算对”，比事后追着代码修偏差更有效。 + +## 适合承载这些高杠杆信息的文档 +- SVG 图 + - 用来表达系统结构、模块关系、关键路径。 +- C4 Dynamic 文档 + - 用来描述运行时对象/模块之间如何协作，约束核心交互过程。 +- Flow 文档 + - 用来描述更细粒度的业务流程、调用顺序和异常分支。 + +## 一句话总结 +- 人类应把注意力从“审每一行代码”，转移到“定义系统该如何被正确实现”。 diff --git a/2Areas/AI工作流/文档优先编程.md b/2Areas/AI工作流/文档优先编程.md index 4ff583d..efb02c4 100644 --- a/2Areas/AI工作流/文档优先编程.md +++ b/2Areas/AI工作流/文档优先编程.md @@ -1,13 +1,104 @@ +## Why +- AI 产出代码的速度远远大于人类 review 的速度，所以人应该把注意力聚焦在高杠杆的位置，而不是把主要精力消耗在逐行看代码上。 +- 文档就是这种高杠杆工具。它能用较小的注意力成本，约束 Agent 对需求、边界、架构和实现路径的理解。 +- 参考：[[人类注意力应分配到高杠杆的点]] -## why? -- Ai 产出代码的速度远远大于人类review的速度，所以人应该聚焦于高杠杆的点，参考[[人类注意力应分配到高杠杆的点]]。而文档就是人可以用最小的注意力就可以规范agent实现需求以及边界的翘点。 -## what? -- 以策划文档发起 -- 第一个文档：PRD - - 内容： -- 第二个文档：根据访谈内容生成的时序图 +## 核心观点 +- 先写文档，不是为了增加流程，而是为了降低实现偏差。 +- 文档优先编程的本质，是先把“要做什么、为什么这样做、做到什么程度算对”说清楚，再让 Agent 批量实现。 +- 如果文档质量足够高，后续代码实现、review、回溯修正都会轻很多。 -## how? -- -- 参考美团AI工作流 -![[美团AI工作流.png]] \ No newline at end of file +## How +下面以 OMX 工作流为例。 + +### 1. 从策划文档发起 +- 输入：策划文档 / 需求文档 / PRD +- 目标：给后续所有文档一个统一的问题定义和业务背景 + +### 2. 通过 `$deep-interview` 产出访谈文档 +- 输入：策划文档 +- 产物：访谈文档 +- 作用： + - 明确目标、边界、本期做什么、不做什么 + - 补充约束条件和项目上下文 + - 沉淀一些和具体项目绑定的技术前提 +- 说明： + - 这份文档更像“给 Agent 用的澄清稿”，用来减少需求理解偏差 + +### 3. 通过 `$alignment-c4-dynamic` 产出 C4 Dynamic 文档 +- 输入：访谈文档 +- 产物：C4 Dynamic +- 作用： + - 描述关键运行时交互 + - 收敛模块边界、接口约定、架构约束 + - 形成较粗粒度的技术方案和协作视图 + +### 4. 通过 `$plan` 产出细化计划文档 +- 输入：访谈文档 + C4 Dynamic +- 产物：Plan 文档 +- 作用： + - 把粗粒度方案继续细化 + - 明确任务拆解、模块边界、接口约定、实施顺序 + - 让后续实现不再依赖临场发挥 + +### 5. 通过 `$ralplan` 产出可执行实现计划 +- 输入：访谈文档 + C4 Dynamic + Plan 文档 +- 产物：Ralplan 文档 +- 作用： + - 把前面的信息进一步压实为“面向执行”的实现计划 + - 让实现阶段的上下文、顺序和约束更集中 +- 当前理解： + - 它位于 Plan 和实际编码之间，作用类似“可直接驱动实现的执行蓝图” + +### 6. 通过 `$alignment-flow ralplan文档` 产出时序图 +- 输入：Ralplan 文档 +- 产物：时序图 / Flow 文档 +- 作用： + - 把关键流程细化到方法、接口、调用顺序和异常分支 + - 用自然语言 + 流程表达把实现细节前置说明清楚 + +### 7. 通过 `$ralph ralplan文档` 产出代码 +- 输入：Ralplan 文档 +- 产物：代码 +- 作用： + - 按前面已经定义好的文档约束进行实现 + +### 8. Review 代码，并把偏差回写到文档 +- 如果没问题： + - 把前面产出的文档整理后沉淀到项目记忆中 +- 如果有问题： + - 先判断问题出在实现，还是出在前置文档本身 + - 很多偏差并不是 Agent “写错了”，而是上游文档没有把关键约束表达清楚 + +## 偏差修正回路 +- 如果差异主要出在 C4 Dynamic： + - 重新跑 `$deep-interview` + - 修正访谈文档 + - 再回到 C4 Dynamic 阶段继续收敛 +- 如果差异主要出在 Plan / Ralplan： + - 重新跑 `$plan` 或 `$ralplan` + - 把差异点回写到访谈文档 + - 再继续推进后续阶段 +- 如果差异主要出在时序图 / Flow： + - 重新跑 `$ralplan` + - 同时把差异回写到 Plan、Ralplan、访谈文档 + - 再进入实现阶段 + +## 实践原则 +- 文档不是“交付物附属品”，而是实现质量的上游控制面。 +- review 不应该只盯代码，也要反查是哪一层文档没有把问题讲清楚。 +- 一旦发现偏差，优先修正文档源头，而不是只在代码层打补丁。 + +## 参考 +- [[AI-First产研团队的交付路径]] + - 需求 / PRD + - 技术方案设计 + - 任务拆解 +![[AI-First描述工作流.png]] + +- [[天猫新品团队AI编码实战指南（下）]] + - 可对照理解为三类核心文档： + - 第一类：需求 / PRD + - 第二类：技术方案 + - 第三类：任务拆分 +![[美团AI工作流.png]] diff --git a/InBox/AI-First产研团队的交付路径.md b/3Resources/AI/AI-First产研团队的交付路径.md similarity index 73% rename from InBox/AI-First产研团队的交付路径.md rename to 3Resources/AI/AI-First产研团队的交付路径.md index e26a2e5..916e74d 100644 --- a/InBox/AI-First产研团队的交付路径.md +++ b/3Resources/AI/AI-First产研团队的交付路径.md @@ -35,14 +35,14 @@ 六个阶段的核心逻辑不是线性流程编排，而是**上下文逐级收敛、阶段持续校验、结果最终回写**。 -| 阶段 | 人的职责 | AI 的职责 | 显性资产（给人的） | 隐性上下文（给下阶段 AI 的） | -|------|----------|-----------|-------------------|---------------------------| -| 业务需求 | 定义目标、边界、优先级 | 起草需求内容 | 需求文档 | 业务意图、边界约束 | -| PRD 设计（write-prd Skill） | 澄清歧义、确认范围 | 生成结构化 PRD | AI 可执行的 PRD | 功能目标、业务规则、验收标准 | -| 技术方案设计（write-tech-design Skill） | 评审架构可行性 | 产出方案初稿 | 技术方案 + API 契约 | 模块边界、接口约定、架构约束 | -| 任务拆解（breakdown-tasks Skill） | 确认优先级与依赖 | 拆解为可执行单元 | WBS 任务列表 | 单任务输入/输出/依赖/验收标准 | -| Daily Coding Agent（编码/单测/CR Skill） | 审核关键逻辑与架构边界 | 编码→单测→CR→修复循环 | 经验证后可交付的代码 | 代码变更记录、新增接口与规则 | -| 上下文更新（update-context Skill） | 审检沉淀结果 | 回写知识与上下文 | 更新后的知识资产 | 下一轮迭代的全量上下文基线 | +| 阶段 | 人的职责 | AI 的职责 | 显性资产（给人的） | 隐性上下文（给下阶段 AI 的） | +| ---------------------------------- | ----------- | ------------- | ------------- | ---------------- | +| 业务需求 | 定义目标、边界、优先级 | 起草需求内容 | 需求文档 | 业务意图、边界约束 | +| PRD 设计（write-prd Skill） | 澄清歧义、确认范围 | 生成结构化 PRD | AI 可执行的 PRD | 功能目标、业务规则、验收标准 | +| 技术方案设计（write-tech-design Skill） | 评审架构可行性 | 产出方案初稿 | 技术方案 + API 契约 | 模块边界、接口约定、架构约束 | +| 任务拆解（breakdown-tasks Skill） | 确认优先级与依赖 | 拆解为可执行单元 | WBS 任务列表 | 单任务输入/输出/依赖/验收标准 | +| Daily Coding Agent（编码/单测/CR Skill） | 审核关键逻辑与架构边界 | 编码→单测→CR→修复循环 | 经验证后可交付的代码 | 代码变更记录、新增接口与规则 | +| 上下文更新（update-context Skill） | 审检沉淀结果 | 回写知识与上下文 | 更新后的知识资产 | 下一轮迭代的全量上下文基线 | **关键洞察**：注意"隐性上下文"这一列——需求阶段提供业务意图，PRD 阶段将意图转为结构化约束，技术方案阶段将约束收敛为技术决策，任务拆解阶段再将决策压缩为最小执行单元。到 Daily Coding Agent 阶段，AI 拿到的已不是一个模糊需求，而是一份高度收敛的任务上下文。 diff --git a/3Resources/AI/AI-First描述工作流.png b/3Resources/AI/AI-First描述工作流.png new file mode 100644 index 0000000..a4f9772 Binary files /dev/null and b/3Resources/AI/AI-First描述工作流.png differ diff --git a/InBox/天猫AI编码实践四文对照整理.md b/3Resources/AI/天猫AI编码实践四文对照整理.md similarity index 100% rename from InBox/天猫AI编码实践四文对照整理.md rename to 3Resources/AI/天猫AI编码实践四文对照整理.md diff --git a/InBox/天猫新品团队AI编码实战指南（下）.md b/3Resources/AI/天猫新品团队AI编码实战指南（下）.md similarity index 100% rename from InBox/天猫新品团队AI编码实战指南（下）.md rename to 3Resources/AI/天猫新品团队AI编码实战指南（下）.md diff --git a/InBox/天猫新品营销技术团队AI编码实战指南（上）.md b/3Resources/AI/天猫新品营销技术团队AI编码实战指南（上）.md similarity index 100% rename from InBox/天猫新品营销技术团队AI编码实战指南（上）.md rename to 3Resources/AI/天猫新品营销技术团队AI编码实战指南（上）.md diff --git a/InBox/清华大学 驾驭工程 Harness Engineering 研究报告.md b/3Resources/AI/清华大学 驾驭工程 Harness Engineering 研究报告.md similarity index 100% rename from InBox/清华大学 驾驭工程 Harness Engineering 研究报告.md rename to 3Resources/AI/清华大学 驾驭工程 Harness Engineering 研究报告.md diff --git a/InBox/640.svg b/InBox/640.svg deleted file mode 100644 index 144b13d..0000000 --- a/InBox/640.svg +++ /dev/null @@ -1,1743 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 可选步骤 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 需求 / PRD -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 分析 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 功能文档 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - 产物 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - review -
-
-
- - - - - - - - - - - - - - - - - - -
-
-
- - - - no -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - ok？ -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 补充或重新生成 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 技术分析，匹配必要的上下文、组件、工作流 -
-
-
- - - - - - - - - - - - - - - -
-
-
-
-
-文档： -
-
-PRD - 原始需求文档 -
-
- - - - 功能文档 - 核心功能与分支运行结果
- - - -技术方案 - 匹配结果，技术选型
- - - -分步文档 - 规划执行流程 -
-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
-知识池
- - - -
- - - -技术方案、组件、工作流、描述文档、...... -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 技术方案 -
-
-
- - - - - - - - - - - - - - - - - - -
-
-
- - - - 匹配 -
-
-
- - - - - - - - - - - - - - - - -
-
-
- - - - 代码仓库 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - review -
-
-
- - - - - - - - - - - - - - - - - - -
-
-
- - - - no -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - ok？ -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 补充或重新生成 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 任务拆解 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - 任务拆分文档 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - no -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - ok？ -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 补充或重新生成 -
-
-
- - - - - - - - - - - - - - - - - - -
-
-
- - - - 可能拆成多个专用工作流 -
-
-
- - - - - - - - - - - - - - - - -
-
-
- - - - 代码生成 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - review -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 代码 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - no -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - ok？ -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 补充或重新生成 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 人工验收与迭代 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - review -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - 打分池 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 代码质量校验 -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
-
-
- - - - 自动化功能验证 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - workflow 1 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - workflow 2 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - workflow 3 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - 关键组件、工作流、知识的识别与沉淀 -
-
-
- - - - - - - - - - - - - - - - - - -
-
-
- - - - 更新 -
-
-
- - - - - - - - - - - - - - - - -
-
-
- - - - 人 -
-
-
- - - - - - - - - - - - - - - -
-
-
- - - - AGENTS -
-
-
- - - - - - - - - -