这份大纲不是目录复印件，而是全书的运行图#

Warning
这份大纲会继续演进。
这本书本身就是一套持续收敛中的 AI Native 工程实践，所以章节标题、案例重心和局部顺序后面还可能继续打磨。

很多技术书的大纲，只能回答“后面大概会写什么”。

这本书不够。它更想回答的是：

为什么读者应该按这个顺序往下读。
为什么项目应该按这个节奏往前推。
哪些能力是全流程伴随的控制面，哪些只是某个阶段才会被逼出来的局部问题。

Important
这不是一本 AI 工具图鉴，也不是一串热词合集。
它真正想教会读者的，是怎么把 AI 从一个时灵时不灵的外挂，变成一套能稳定推进真实项目的工程工作流。

Tip
如果想看每个 Part 的目标和每一章更细的落点，可以继续看《详细版》。

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

不是只会“用一个 AI IDE”，而是知道怎么把旧脑回路彻底掰过来。
不是只会“让 AI 写点代码”，而是知道项目怎么收敛、怎么起盘、怎么长主干、怎么接世界、怎么长期运行。
不是只看单点提效，而是逐步把 AI 用成一个可控、可复用、可治理的生产系统。

目录为什么按这个顺序排#

这本书的结构，核心就三条。

Part 1 先完成认知冷启动，不急着推进正式实现。
从 Part 2 开始，全书沿着项目生命周期往前走。
Rules、Skills、Context、Harness、MCP、Playwright、Agent Team、成本治理这些能力，都按“贯穿能力”来写，而不是按“阶段外挂”来写。

换句话说，这本书不是先讲一堆概念，再临时拼一个 demo 验证；而是先把脑回路、控制面和主线项目立住，再把整条 how loop 一路跑穿。

贯穿全书的四条暗线#

认知冷启动线#

为什么很多人觉得 AI 很笨。
为什么工具不是信仰。
为什么 Prompt、Context、Harness 最后会收束成控制面。

产品判断线#

从 PRD、范围裁剪、验收标准，到优先级管理、版本规划、上线判断。
这一条线会自然带出 AI Product Manager 的能力，但不会被写成一本独立的产品教材。

控制面资产线#

Prompt、Context、AGENTS.md、Rules、Skills、SOP、Spec、模板、命令入口，都会随着项目推进不断沉淀。
重点不是背名词，而是知道什么该沉淀、什么时候沉淀、沉淀成什么形态最值钱。

验证与治理线#

调试、自洽陷阱、测试、回滚、审计、熔断、成本治理、共享记忆、Agent Team、反脆弱 Harness，会随着项目复杂度一起升级。
它们不是最后补上的收尾动作，而是从项目早期就开始埋下去的治理底座。

全书主线怎么推进#

Part 1 · 破局#

这一部分先不急着写项目实现，先把读者从“AI 只是高级补全”的旧脑回路里拉出来，然后把主线项目真正亮出来。

这一部分会回答：

为什么 AI 编程不是单纯模型变强，而是协作方式整体换代。
为什么 Native IDE、IDE 插件、CLI、Web Agent、SpecDriven 工具各有生态位。
为什么 Prompt、Context、Harness 最后会收束成控制面。
为什么 AI 一提速，先被放大的反而是产品判断能力。
为什么这本书必须拿一个真实的大项目开刀，而不是用轻量 demo 糊过去。

对应文章：

Part 2 · 定盘#

这部分才正式进入项目生命周期。目标不是“赶紧写功能”，而是把 PRD、范围、技术栈、仓库结构、系统设计和规范底板一次立稳。

这一部分会回答：

怎么做需求收敛、范围裁剪和验收口径前置。
怎么把技术栈和宿主边界定到“够开工”，但不提前把未来拍死。
为什么 workspace、目录结构、环境边界、命令入口必须先统一。
为什么系统设计不是文档装饰，而是 AI 协作真正的契约底板。
为什么 discussion、issue、proposal、design、specs、tasks 必须被收成一条 spec-first 控制面流程。

对应文章：

Part 3 · 长主干#

这部分直接盯着主干开发里最容易失控的几件事。

这一部分会回答：

tasks.md 怎样从施工顺序单长成真正能跑的 Execution Graph。
为什么项目必须先围着主资产收官方路径，而不是让 AI 顺手把副线全铺开。
事实层、证据层、投影层为什么一混，项目就会越做越假。
开发期 Harness 到底该怎么长，为什么 guardrails 不是它的全部。
长任务为什么经常一断就重来，progress log、handoff artifact、repo memory 又该怎样设计。

对应文章：

Part 4 · 接世界#

这部分解决的不是“还能再写多少功能”，而是怎么让 agent 真正看见运行时世界，并把外部系统和交付闭环一起接进来。

这一部分会回答：

CLI 为什么不只是命令入口，而是运行时观察面的第一入口。
Playwright 为什么不只是测试工具，而是运行时 verifier。
数据库、第三方 API、文件系统、IPC 和宿主边界怎么进入同一条 loop。
联调、验收、发布、回退和人工升级，为什么必须被设计成默认流程。

对应文章：

Part 5 · 自运行#

当项目真的跑起来之后，问题会自然抬升到成本、长期记忆、Agent Team、反脆弱 Harness 和人类角色升级。这里讨论的已经不只是“怎么做完”，而是“怎么一直跑”。

这一部分会回答：

为什么真正贵的不是 token，而是整条交付链的低质量吞吐。
什么必须写回 repo 成为 system of record，什么必须及时忘掉。
MultiAgent / Agent Team 什么时候真的值钱，什么时候只是在并行复制混乱。
为什么成熟的 Harness 不只是会防错，还会因为失败变稳。
当执行越来越自动化之后，人类真正该退到系统的哪个位置。

对应文章：

读者该怎么用这份大纲#

如果只是想先判断这本书值不值得读#

先看 Part 1 和这份大纲。只要认同“AI 编程的核心问题不是工具本身，而是工作流与控制面”，这本书后面的内容基本就对路了。

如果已经在用 Cursor、Claude Code 或其他 CodeAgent#

别急着直接跳到后面。很多人以为自己缺的是更强模型，实际缺的是需求收敛、边界定义、Harness、verifier 和治理。这份大纲可以帮助快速定位自己到底卡在哪一层。

如果是想按项目主线系统推进#

最稳的读法还是按 Part 顺序往下走。因为这本书默认不是“概念分栏阅读”，而是“一条项目主线从冷启动一路推进到长期运行”的路线。

最后一句话#

这本书最终要回答的，不是哪一个工具最强，而是：

怎样让一个真实项目从旧脑回路被打破开始，到拿到 PRD、完成交付，再到长期运行，都能在 AI 的帮助下被稳定推进。

导览版

这份大纲不是目录复印件，而是全书的运行图#

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

目录为什么按这个顺序排#

贯穿全书的四条暗线#

认知冷启动线#

产品判断线#

控制面资产线#

验证与治理线#

全书主线怎么推进#

Part 1 · 破局#

Part 2 · 定盘#

Part 3 · 长主干#

Part 4 · 接世界#

Part 5 · 自运行#

读者该怎么用这份大纲#

如果只是想先判断这本书值不值得读#

如果已经在用 Cursor、Claude Code 或其他 CodeAgent#

如果是想按项目主线系统推进#

最后一句话#