详细版是给想看“施工细节”的读者准备的#

如果前一页的导览版负责回答“这本书大概怎么走”，这一页负责回答“为什么这样排，以及每一段具体想解决什么问题”。

它保留了更接近原始 OUTLINE.md 的表达密度，但做了适合文档阅读的格式整理。换句话说，这一页不是仓库工作底稿的生搬硬贴，而是读者可读版。

Warning
这一页同样会跟着全书规划一起高频变化。
如果几天后再回来看，章节标题、分组顺序、重点案例和措辞细节出现调整，不代表前后矛盾，而代表这本书还在持续迭代。

Tip
如果只想快速判断阅读顺序，先看《导览版》更高效。

总纲#

这本书真正要教会读者什么#

这不是一本 AI 工具图鉴，也不是一堆热词的科普合集。
这本书真正要教会读者的，是怎么把 AI 从一个时灵时不灵的外挂，变成一套能稳定推进真实项目的工程工作流。
读者读完之后，应该不只会“用一个 AI IDE”，而是能理解: 从旧脑回路怎么被打破，到项目怎么收敛、怎么起盘、怎么开发、怎么验收、怎么发布、怎么治理。
再往后一步，不只是个人提效，而是把 AI 用成一个可控、可复用、可治理的生产系统。

这次目录重排的关键原则#

Part 1 必须保留，而且必须有意义。它不负责正式推进项目实现，但它负责把读者脑子掰过来。如果没有这层认知冷启动，后面的项目主线很容易又被读回“AI 帮我写代码”的老路。
从 Part 2 开始，整本书按项目生命周期推进。 Part 1 先完成认知冷启动，并把主线项目亮相。Part 2 才正式从 PRD、范围、技术栈、架构、仓库和规范开始起盘。后面的开发、交付、治理都顺着项目生命周期继续往下走。
Rules、Skills、Context、Harness、MCP、Playwright、成本与护栏，都是贯穿能力，不是阶段性插件。它们不是“到了某个 Part 才突然出现”的外挂，而是从项目起盘开始一路伴随，只是在不同阶段承担的角色和重要性不一样。
知识点要由项目自然逼出来，但不牺牲前置认知引子。有些文章的职责不是推进进度，而是建立最小心智框架；有些文章的职责才是把项目往前推。这两类内容不能互相替代，但必须顺滑衔接。

贯穿全书的四条暗线#

认知冷启动线。为什么很多人觉得 AI 很笨，为什么工具不是信仰，为什么 Prompt、Context、Harness 最后会收束成控制面。
产品判断线。从 PRD、范围裁剪、验收标准，到优先级管理、版本规划、上线判断。这里会自然带出 AI Product Manager 的思路，但不会把它单独写成一本产品书。
控制面资产线。 Prompt、Context、AGENTS.md、Rules、Skills、SOP、Spec、模板、命令入口，都会随着项目推进不断沉淀。重点不是“学会一个名词”，而是知道什么该沉淀、什么时候沉淀、沉淀成什么形态最值钱。
验证与治理线。调试、自洽陷阱、测试、回滚、审计、熔断、成本治理、共享记忆、Swarm、反脆弱设计，都会随着项目复杂度逐步升级。它们不是最后才聊的收尾话题，而是从项目早期就不断埋下去的暗线。

项目主线怎么穿#

Part 1 先把脑回路掰过来，再把项目亮出来#

先回答“为什么旧工作流不够用了”。
再回答“为什么后面必须拿一个真实项目开刀”。

Part 2 正式拿到项目并定盘#

从 PRD、需求收敛、技术栈、架构、仓库和规范开始。
让项目进入“可以稳定推进”的状态。

Part 3 把主干写出来#

后端、前端、实时链路、异步任务都在这里开始长出来。
调试、验证、护栏、Context 输入也会在这里持续出现。

Part 4 把项目真正跑通#

让 CLI、Harness、MCP、Playwright、跨端宿主、联调和发布形成闭环。
让项目从“能写代码”变成“能真正交付”。

Part 5 把这套工作流放大#

成本、共享记忆、Swarm、反脆弱设计和角色升级，会在这里被系统化。
目标不再只是做完这个项目，而是让这套方法能长期跑下去。

Part 1 · 破局#

目标: 这一部分不正式推进项目实现，而是先建立后文所需的最小心智框架。现在已经写出来的前三篇文章必须保留，因为它们承担的就是“让后文能成立”的引子职责。

1.1 为什么很多人觉得 AI 很笨: 其实是工作流还停在补全时代#

从“你写 AI 补”到“你说 AI 做”，中间到底变了什么。
AI 编程为什么不只是模型变强，而是协作方式、交互方式和开发模式一起变了。
这一章负责打破“问题都在模型”的旧误解。

1.2 工具不是信仰: 不同产品形态到底在解决什么问题#

Native IDE、IDE 插件、CLI、Web Agent、Spec 工具分别擅长什么，不擅长什么。
为什么“找本命工具”越来越不重要，真正重要的是岗位分工与场景匹配。
这一章负责建立“工具不是玩具箱，而是岗位体系”的意识。

1.3 从 Prompt 到 Context 再到 Agent Harness: 先把控制面的轮廓看见#

Prompt 解决任务入口，Context 解决材料分发，Harness 解决执行闭环。
为什么只会写 Prompt 很快会撞墙，为什么 Context 多了也不等于更好。
这一章负责把前两篇的认知收束成控制面轮廓。

1.4 AI 时代为什么先被放大的不是代码生成能力，而是产品判断能力#

为什么 AI 一提速，最先暴露的反而是目标模糊、范围失控和优先级混乱。
AI Product Manager 到底是一种什么能力，而不是一个空名词。
这一章负责把“项目主线应该从产品判断开始”这件事先种进读者脑子里。

1.5 把主线项目亮出来: 为什么这本书要拿一个真正的大项目开刀#

为什么不能拿一个轻量 demo 去承载整本书。
主线项目为什么必须同时带着多端、实时、隐私、自动化和治理压力。
GraphSpec 为什么适合作为这本书的真实战场。

Part 2 · 定盘#

目标: 这一部分才正式进入项目生命周期。任务不是“开始写功能”，而是先把 PRD、范围、技术栈、架构、仓库和规范定下来。

2.1 拿到 PRD 后先做什么: 需求收敛、范围裁剪与验收口径#

怎么从“想做很多东西”收敛到“这一版到底先打哪一仗”。
哪些需求是真主线，哪些是未来增强项，哪些应该直接砍。
验收标准为什么必须前置，而不是功能写完之后再补。

2.2 技术栈定盘: 桌面、移动、Web、API、Worker 到底怎么拆#

为什么桌面端、移动端、Web 端不该为了“统一”而强行同构。
技术栈选型要服务于宿主能力、平台边界和长期维护，而不是只服务于短期复用率。
这一章把主线项目的底板钉牢。

2.3 仓库起盘: workspace、目录结构、环境与命令入口先搭起来#

从 monorepo / workspace 到 apps / packages，到底怎么拆更适合 AI 协作。
哪些命令必须一开始就统一，哪些脚手架和模板值得提前搭好。
为什么“先把命令入口和环境边界定清楚”会极大降低后面返工。

2.4 系统设计: 架构、数据、接口、模块边界先立住#

为什么真正的 AI 协作不是边写边猜，而是先把系统骨架和契约立起来。
数据模型、接口合同、模块边界、实时链路分别怎么先定清楚。
这一章会把“系统设计”从文档装饰拉回实际控制面。

2.5 规范先行: Spec、Rules、Skills、SOP、模板和代码生成怎么落地#

什么应该写进 AGENTS.md，什么应该变成 Rules，什么应该沉淀成 Skills 或 SOP。
为什么这些资产不是开发中途才补，而是起盘时就该有第一版。
如何让“项目规范”变成 AI 真能用的控制面，而不是人类自己感动自己的文档。

Part 3 · 开发#

目标: 这一部分不只是“写后端、写前端”，而是让项目主干在真实工作流里长出来。开发、调试、验证、Context 输入和护栏会一起出现。

3.1 用 AI 拆第一批任务: 从需求收敛结果到待办、里程碑和执行节奏#

怎么把定盘阶段的输出转成第一批可执行任务。
人类该盯什么，AI 该先做什么，哪些任务适合并行，哪些不能乱并行。
这一章会把项目管理真正接进 AI 协作链路里。

3.2 后端主线: 让 PostgreSQL、服务层、契约层和实时链路一起长出来#

从 Schema、服务层、接口层到实时事件的拆解路径。
为什么真正难的不是让 AI 帮忙写接口，而是让后端底座稳得住。
这一章也会自然带出契约生成、Worker、异步任务和状态一致性问题。

3.3 前端主线: 不是堆页面，而是先把组件协议、状态边界和多端策略讲清楚#

从设计稿、组件树、状态流到页面增量生成的拆解路径。
用户端、中后台、复杂工作台界面分别该怎么设计协作策略。
多端并不意味着所有 UI 都共享，而是先把“该共享什么、不该共享什么”说清楚。

3.4 开发中的护栏: 调试失控、自洽陷阱、测试、回滚和审计怎么一起上场#

为什么开发更快了，调试反而可能更痛苦。
为什么不能让 AI 自己给自己打分，最危险的是自洽，不是报错。
Rules、Skills、测试、回滚、审计、熔断怎么在开发过程中就持续出现，而不是出事后才补锅。

3.5 开发中的 Context 输入: 设计稿、文档、任务系统、数据库、日志和知识库怎么喂给 AI#

外部信息什么时候应该实时读取，什么时候该沉淀成长期资产。
MCP 为什么不只是“高级插件”，而是项目越做越大时的信息输入主干。
这一章解决的是“开发中材料怎么进工作流”。

Part 4 · 交付#

目标: 这一部分解决的不是“再加功能”，而是让项目真正跑流程、做联调、过验收、能发布。CLI、Harness、Playwright、跨端宿主和联调闭环都会在这里系统化。

4.1 CLI 与 Harness: 终端为什么是很多高价值任务真正的施工现场#

为什么很多任务最终都要落到脚本、命令、构建、部署和流水线上。
受控执行环境、运行时可见性、机械验证、失败收敛为什么缺一不可。
这一章会把项目从“能写代码”推进到“能真正跑流程”。

4.2 Playwright 与多模态执行: 让 AI 真正有眼睛和手#

浏览器自动化如何承担 UI 验证、流程回归、截图对比和定位问题。
为什么 Playwright 的价值不只是测试，而是可观察、可复查、可回放。
当前端问题不再只靠“你描述一下页面错哪了”，协作方式会怎么变化。

4.3 跨端与宿主落地: 当项目不只跑在浏览器里，边界要怎么真正落代码#

Tauri、Wujie、桌面端、移动端宿主通信这些边界怎么先定义再实现。
当项目开始碰到本地能力、文件系统、IPC、打包和平台差异时，控制面该怎么升级。
这一章不是为了炫跨端，而是把真实边界真正补全。

4.4 联调、验收与发布: 真正的工作流，不到上线那一刻都不算完#

CLI、Harness、MCP、Playwright、日志、测试、AICR 在联调阶段怎么串起来。
AI 怎么参与 bugfix、回归、变更说明、发布检查与交付交接。
经验怎么在每次交付后回写成 Rules、Skills、模板和知识资产。

Part 5 · 放大#

目标: 当项目真的被做起来之后，问题会自然抬升到成本、共享记忆、多 Agent 编排和系统反脆弱。这里不再只是讨论“怎么做完”，而是讨论“怎么长期跑”。

5.1 成本治理: 真正贵的不是 token，而是低质量上下文和无效返工#

为什么很多人觉得 AI 贵，本质上不是模型太贵，而是工作流太浪费。
模型分层、任务分层、上下文预算、额度窗口、重试策略怎么一起设计。
成本治理为什么应该从项目启动就进入视野，而不是最后才看账单。

5.2 共享记忆与 Context 治理: 系统该记住什么，又该忘掉什么#

为什么多轮任务之后，AI 很容易被旧上下文、旧实现、旧结论带偏。
共享记忆区、决策日志、知识库、索引系统分别适合存什么。
顺序、频率、重复引用、时效性、迁移期共存这些因素会怎么影响 AI 判断。

5.3 Swarm 编排: 多 Agent 协作不是多开几个窗口那么简单#

PM Agent、架构 Agent、开发 Agent、测试 Agent、发布 Agent 分别该做什么。
多 Agent 系统里，任务拆分、职责边界、共享上下文、冲突控制怎么设计。
为什么没有编排层，多 Agent 只会把混乱放大得更快。

5.4 反脆弱设计: 让系统在失败里收敛，而不是在幻觉里互相放大#

API 幻觉、错误引用旧路径、上下文污染为什么会在多 Agent 系统里级联放大。
交叉验证、失败归因、决策复盘、记忆更新怎么形成真正的学习闭环。
这一章要解决的，不是“怎么不出错”，而是“出错后系统怎么变得更稳”。

5.5 角色升级: AI Product Manager、项目经理、架构师以后最值钱的是什么#

AI 时代，最值钱的不会只是“会写实现”的人，而是能定义问题、设计流程、兜住底线的人。
产品判断、项目推进、架构决策和最终责任会怎样重新组合。
这一章会给整本书一个真正的收束: 人类到底该成长成什么样的控制面设计者。

最后一句话#

这本书最终要回答的，不是“哪个工具最强”，而是: 怎样让一个项目从旧脑回路被打破开始，到拿到 PRD、完成交付，再到长期运行，都能在 AI 的帮助下被稳定推进。