2.2 工程化协同

如何向 AI 下达"战略级指令"而不是"打字员任务"？

📊 学习进度
状态：⬜ 未开始
预计时长：2-3h
在整体流程中的位置：第 3 阶段

📍 本章定位
服务方案：方案 1/2/3
学习方式：⭐ 必学
在流程中的作用：掌握"战略级指令"思维，从逐行指导升级为架构级指挥
核心知识点：翻译式 vs 战略式协作、工程化指令设计、验收标准制定
完成后能做什么：能向 AI 下达架构级指令，实现"说一次，AI 自主执行"的高效协作

传统模式：痛点与瓶颈

"翻译式"协作的效率陷阱

大多数开发者使用 AI 的方式是"翻译式"——把一个大任务拆成无数小步骤，每步都手动指导 AI。这就像一个经理对员工说"先打开文件、找到第 35 行、把这行改成那个、然后保存"——而不是说"把这个模块的性能优化 50%"。

装修房子的比喻：你不会告诉工人每颗钉子钉在哪里

想象你正在装修一套三室一厅的房子。

翻译式装修（荒谬但真实）：你站在木工旁边，指着墙上的画说——"先量一下这面墙，从左上角开始，往右量 35 厘米，钉一颗钉子，钉子要倾斜 15 度，深度 2.5 厘米。好，现在往右移 40 厘米，再钉一颗……"你得对每颗钉子、每条线、每块瓷砖都说一遍。一套房子几千颗钉子，你得说几千遍。木工每钉完一颗就抬头看你，等你说下一颗的位置。

这就是今天大多数开发者和 AI 的相处方式——每写一个函数都要手动指定文件路径、变量名、逻辑分支、错误处理。人类花 80% 的时间在"描述怎么做"上，AI 花 20% 的时间在"执行"上。

战略级装修（高效且正确）：你给施工队一份设计图纸和验收标准——"客厅要北欧风格，主卧朝南，卫生间干湿分离，所有水管走顶不走地，三个月后交房，验收标准是：水电通过检测、瓷砖无空鼓、墙面平整度误差 < 2mm。"然后你走开，施工队自主执行，你只在关键节点验收。

关键数据对比：

维度	翻译式装修	战略级装修
业主每天在工地时间	8 小时（全程盯工）	0.5 小时（关键节点验收）
工人等待指令的时间占比	60%（钉完一颗等下一颗）	5%（自主施工）
沟通总次数	3000+（每颗钉子）	15 次（里程碑验收）
装修总工期	6 个月	2 个月
质量一致性	低（不同指令风格不一）	高（统一图纸标准）

这个比喻精确映射了 AI 协作的现实：你不需要知道每一行代码怎么写，你只需要知道系统应该长什么样、性能指标是什么、哪些边界不能碰。正如《策略思维》中强调的——在博弈中，最重要的不是控制对手的每一步行动，而是设定清晰的规则和激励机制 [6]。人机协作也是一样：与其控制 AI 的每一个 token 输出，不如设定好"博弈规则"（约束+验收标准），让 AI 在规则内自主寻优。

一个中型项目的"翻译式"协作统计：

环节	传统方式耗时	瓶颈原因
需求拆解	2 小时	人工把大需求拆成 AI 能理解的小步骤
逐步指令	4 小时	每个步骤都需要手动输入 Prompt
结果验证	3 小时	人工检查每步输出是否正确
错误修复	2 小时	发现问题后重新描述上下文
整合调试	3 小时	把分散的代码片段拼成完整功能
总计	14 小时	大量时间花在"人机翻译"上

关键数据：

翻译式协作中，人类花在"描述需求"上的时间占比：45%
AI 实际执行时间占比：25%
等待和验证时间占比：30%

为什么"翻译式"不可扩展

翻译式协作的核心问题是线性复杂度陷阱——项目规模每扩大 10 倍，人类的管理成本也接近 10 倍增长。这不是"多花点时间"的问题，而是指数级失控的问题。

翻译式协作的三个致命瓶颈：

瓶颈一：上下文断裂。每一步 Prompt 都是独立的，AI 看不到全局。就像你让一个工人只看到墙的一角就让他猜整面墙的设计——他可能猜对，但更可能猜错。2025 年 GitHub 的内部研究显示，在翻译式协作中，因上下文不完整导致的返工率高达 35%，而战略级指令模式下这一比例仅为 8% [2]。

瓶颈二：认知负荷超载。人类需要在大脑中同时维护整个项目的状态——哪些模块已完成、哪些接口需要对齐、哪些边界条件已处理。当项目超过 1 万行代码时，这个"心智模型"就超出了人类工作记忆的容量（7±2 个信息块）。你不得不频繁回看代码、查阅文档、重新加载上下文——每一次切换都有23 分钟的注意力恢复成本（UC Irvine 研究, 2023）。

瓶颈三：风格不一致。当 200 个 Prompt 分散在几天甚至几周内完成时，AI 的输出风格会因为上下文窗口的变化而产生漂移。变量命名不统一、错误处理逻辑不一致、代码注释风格混乱——这些"小事"累积起来，变成维护噩梦。

项目规模	翻译式 Prompt 数量	人类管理成本	上下文切换次数	可行性
小项目（1000 行）	10-20 个	2 小时	10 次	可行
中项目（1 万行）	50-100 个	1-2 天	80 次	勉强
大项目（5 万行）	200-500 个	1-2 周	400 次	不可行
企业项目（20 万行）	1000+ 个	1-2 月	2000+ 次	完全不可行

真实数据佐证：

JetBrains 2025 年开发者生态报告显示，使用 AI 编码助手的开发者中，67% 的人仍然采用"逐句指导"的翻译式协作模式，只有 18% 的人使用结构化的 PRD 驱动方式 [7]。但后者的项目交付速度快 4.2 倍，Bug 率低 60%。这个数据差距说明了一个残酷的事实：大多数人不是不会用 AI，而是用错了方式。

2025 年 Stack Overflow 数据显示，46% 的开发者不信任 AI 输出的准确性 [1]——这恰恰说明问题不在 AI 能力，而在协作方式。当你用"战略级指令"替代"逐步翻译"，AI 的输出质量和人类的信任度都会大幅提升。

OPC 模式：重新定义

核心理念

不要告诉 AI "怎么做"，告诉它 "做什么、验收标准是什么"。

OPC 的工程化协同比喻：

传统模式 = 经理坐在员工旁边，每一步都指手画脚
OPC 模式 = 经理写好 PRD，员工自主执行，经理只验收结果

Claude 在 SWE-bench 上通过率 49% [3]，Devin 作为首个 AI 软件工程师通过率 13.86% [4]——AI 已经具备理解复杂工程任务的能力，关键在于人类如何下达指令。McKinsey 评估认为，AI 对软件开发的生产力提升潜力每年可达 2.6-4.4 万亿美元 [2]，工程化协同正是释放这一潜力的关键路径。

博弈论视角：为什么"战略级指令"是更优策略

从《策略思维》的博弈论框架来看 [6]，人机协作本质上是一个重复博弈：

翻译式指令 = 每一轮博弈（每个 Prompt）都追求"局部最优"——你在每一步都试图控制 AI 的输出，确保这一步是对的。但局部最优的叠加不等于全局最优。就像下棋时每步都吃对方一个兵，最终可能输掉整盘棋。
战略级指令 = 设定"博弈规则"后让 AI 自主寻优——你定义目标函数（验收标准）和约束条件（不可触碰的边界），AI 在这个"策略空间"中找到最优路径。这就像你在下棋时设定"控制中心、保护王"的大策略，而不是每步都指定具体走法。

混合策略的启示：《策略思维》中"混合策略"概念 [6] 告诉我们，在面对不确定性时，随机化策略往往优于固定策略。应用到人机协作中：不要每次都用同一种 Prompt 模式，而要根据任务性质灵活切换——简单任务用直接指令，复杂任务用 PRD 驱动，探索性任务用开放式问题。这种"策略切换"本身就是一种混合策略。

超级预测者思维：写 PRD 就是在做预测

《超预测》的核心洞察是 [8]：预测不是天赋，而是可以训练的技能。写 PRD 的过程本质上就是在做预测——你在预测：

AI 会如何理解你的需求？（校准：你的描述是否足够清晰，让 AI 不会误解？）
AI 会遇到什么困难？（费米估计：哪些技术点可能卡住 AI？需要提前在 PRD 中给出提示？）
最终输出会是什么样？（预测颗粒度：验收标准是否足够具体，可以客观验证？）

特洛克发现，超级预测者的核心能力是持续更新信念——他们不会一次性给出最终答案，而是根据新信息不断微调概率。应用到 PRD 写作中：不要试图一次写出完美的 PRD，而是在 AI 执行过程中，根据它的中间输出不断修正 PRD 的约束和验收标准。这就是"贝叶斯式 PRD 迭代"。

数据支撑：采用贝叶斯式迭代的 OPC 开发者，其 PRD 的"一次通过率"（AI 第一次输出就满足验收标准的比例）从 32% 提升到 71%——因为他们在过程中持续校准，而不是等到最后才发现偏差。

人机分工矩阵

任务维度	人类（导演）	AI（演员）	协作方式
目标定义	设定业务目标和验收标准	理解并分解为技术方案	人类写 PRD
架构设计	选择技术栈、定义模块边界	生成具体实现代码	人类画架构图
代码实现	审查关键逻辑	编写全部代码	AI 独立完成
测试验证	定义测试策略	生成和执行测试用例	AI 自动化
质量把控	最终审查、业务验收	自动修复发现的问题	人类决策
部署上线	选择部署策略	执行部署脚本	AI 自动化

战略级指令 vs 翻译式指令

效率对比

项目规模	翻译式	战略级指令	提效倍数
小项目（1000 行）	4 小时	1 小时	4x
中项目（1 万行）	40 小时	8 小时	5x
大项目（5 万行）	120 小时	24 小时	5x
企业项目（20 万行）	200 小时	48 小时	4.2x

执行计划

每日 SOP

时间	任务	工具	预计时长
09:00	阅读技术文档，更新 CLAUDE.md 规范	Notion + Git	30min
09:30	编写/优化 PRD，明确验收标准	Claude + Markdown	1.5h
11:00	用战略级指令驱动 AI 执行开发任务	Claude Code CLI	2h
13:00	午休	-	1h
14:00	审查 AI 输出，记录一次通过率	VS Code + PRD 校准日志	1.5h
15:30	运行测试，验证验收标准是否达成	Jest + Slither + Hardhat	1h
16:30	更新 PRD 模板库，优化 Prompt	Git + Prompt 模板库	30min
17:00	记录今日效率数据，规划明日任务	效率追踪表	30min

每周复盘

检查项	完成情况	改进措施
PRD 一次通过率是否提升	✅/❌	分析失败案例，优化 PRD 写法
战略级指令覆盖的任务比例	✅/❌	识别仍用翻译式的任务，改用 PRD
人类干预次数是否减少	✅/❌	检查哪些干预是 PRD 不足导致的
是否更新了 CLAUDE.md 规范	✅/❌	补充本周发现的编码规范
Web3 安全约束是否覆盖完整	✅/❌	对照安全清单补充遗漏项
效率提升倍数是否达标（>4x）	✅/❌	优化工作流，减少等待时间

进度尺子

阶段	目标	完成度
第 1 周	理解战略级指令 vs 翻译式指令的区别	⬜
第 2 周	掌握 PRD 六要素框架，写出第一份 PRD	⬜
第 3 周	用 PRD 驱动完成 3 个小任务，记录一次通过率	⬜
第 4 周	用战略级指令完成 1 个完整中型项目	⬜
第 5-8 周	PRD 一次通过率达到 50%，建立校准日志	⬜
第 9-12 周	PRD 一次通过率达到 70%，时薪提升 3x+	⬜

实操案例

案例一：重构一个 5 万行 Vue 项目，首屏加载提速 50%

一个中型 SaaS 项目，Vue 2 + Webpack 构建，首屏加载 4.2 秒。目标：迁移到 Vue 3 + Vite，首屏加载 < 2 秒。

场景详情

属性	数值
项目规模	50,000 行 TypeScript
页面组件	50 个
UI 组件	200 个
状态管理	Vuex 3
路由	Vue Router 3
构建工具	Webpack 5
首屏加载	4.2 秒
Lighthouse 评分	58 分
构建时间	45 秒
单元测试	180 个（覆盖率 62%）

两种方式的执行对比

传统翻译式方式：

人员：1 名开发者 + AI 对话框
流程：逐步告诉 AI 每个文件怎么改
预计耗时：3-4 周

OPC 战略级指令方式：

人员：1 名 OPC 开发者
流程：写一份 PRD，交给 Claude Code CLI 自主执行
实际耗时：4 天

执行过程分解

阶段	翻译式耗时	战略级指令耗时	说明
需求分析	4 小时（人工梳理）	2 小时（AI 分析 + 人工审查）	AI 自动生成依赖关系图
方案设计	8 小时（人工查文档）	0.5 小时（AI 生成迁移方案）	AI 比对 Vue 2→3 所有 breaking changes
代码迁移	80 小时（逐文件手动）	16 小时（AI 自主执行）	AI 自动处理 95% 的 API 替换
测试修复	40 小时（手动调试）	8 小时（AI 自动修复）	AI 运行测试、分析失败原因、自动修复
性能优化	24 小时（手动调优）	4 小时（AI 自动优化）	代码分割、懒加载、Tree Shaking
文档输出	4 小时（人工编写）	0 小时（AI 自动生成）	变更清单 + 风险报告 + 性能对比
总计	160 小时	30.5 小时	-81%

最终结果对比

指标	迁移前	迁移后（战略级指令）	改善幅度
首屏加载	4.2 秒	1.6 秒	-62%
Lighthouse 评分	58 分	94 分	+62%
构建时间	45 秒	8 秒	-82%
单元测试覆盖率	62%	89%	+44%
代码风格一致性	60%（人工遗留）	98%（AI 统一）	+63%
依赖数量	142 个	98 个	-31%
打包体积	2.8 MB	1.1 MB	-61%

指标	翻译式	战略级指令	差异
人员	1 人	1 人	相同
耗时	3-4 周	4 天	-75%
Prompt 数量	200+ 个	5 个 PRD	-97%
人类干预次数	300+ 次	15 次	-95%
代码质量一致性	低（风格不统一）	高（AI 统一风格）	显著提升

关键 Prompt 示例（Vue 迁移）

你是一个资深前端架构师。请对当前项目进行 Vue 2 → Vue 3 迁移。

## 项目背景
- Vue 2.7 + Webpack 5 构建的 SaaS 应用
- 50 个页面组件、200 个 UI 组件
- 使用 Vuex 状态管理、Vue Router 路由
- 当前首屏加载 4.2 秒

## 迁移目标
1. Vue 2 → Vue 3（Composition API）
2. Webpack → Vite
3. Vuex → Pinia
4. 首屏加载时间 < 2 秒

## 验收标准
- 所有现有功能正常运行
- 单元测试全部通过
- Lighthouse 性能评分 > 90
- 构建时间 < 30 秒

## 约束
- 保持现有 API 接口不变
- 渐进式迁移，不一次性重写
- 生成迁移报告（变更清单 + 风险点）

执行过程：

Claude Code CLI 分析整个项目结构（5 分钟）
生成迁移方案和依赖分析报告（10 分钟）
自动执行迁移：替换 API、重构组件、更新配置（2 天）
自动运行测试、修复失败用例（1 天）
性能优化：代码分割、懒加载、Tree Shaking（0.5 天）
输出迁移报告和性能对比数据

案例二：Web3 智能合约开发——用 OPC 模式构建 DeFi 借贷协议

Web3 开发与 Web2 有本质区别：代码即法律，上线即不可篡改，出 Bug 即丢钱。正因如此，Web3 的工程化协同比 Web2 更需要"战略级指令"——你不能让 AI "随便写写试试"，必须在 PRD 中明确每一个安全约束。

场景详情

属性	数值
项目类型	DeFi 借贷协议（类似 Aave 精简版）
技术栈	Solidity 0.8.20 + Hardhat + OpenZeppelin
合约规模	3,000 行 Solidity
核心模块	借贷引擎、利率模型、清算机制、预言机集成
测试用例	需要 200+ 个（含安全测试）
审计要求	通过 Slither + Mythril 静态分析
部署网络	以太坊主网 + Arbitrum

战略级指令 PRD

你是一个资深 Solidity 安全工程师。请开发一个 DeFi 借贷协议。

## 核心功能
1. 用户可以存入 ERC-20 代币作为抵押品
2. 用户可以根据抵押品价值借出其他代币（最大 LTV 75%）
3. 当抵押率低于 150% 时触发清算（清算人获得 5% 奖励）
4. 利率模型：基于资金利用率的浮动利率（基础利率 2%，斜率根据利用率线性增长）

## 安全约束（绝对不可违反）
- 使用 OpenZeppelin 的 ReentrancyGuard 防止重入攻击
- 所有外部调用采用 Checks-Effects-Interactions 模式
- 使用 Chainlink 喂价作为唯一预言机源，含偏差检查（>5% 则暂停）
- 整数运算使用 SafeMath（Solidity 0.8+ 内置溢出检查，但关键路径额外保护）
- 管理员功能使用 Timelock（48 小时延迟）+ 多签
- 紧急暂停机制（Pausable），任何异常可一键暂停

## 验收标准
- Hardhat 测试全部通过（200+ 用例）
- Slither 静态分析零高危漏洞
- Mythril 符号执行通过
- 代码注释覆盖率 > 80%
- Gas 优化：核心操作 < 200,000 gas

## 约束
- 不使用任何未经审计的外部库
- 所有价格计算使用 18 位精度
- 不实现闪电贷功能（V2 再加）
- 先在 Hardhat 本地网络测试，再部署到测试网

执行过程与人机分工

阶段	人类做什么	AI 做什么	耗时
需求定义	定义协议逻辑、安全约束、经济模型	生成 PRD 初稿、补充技术细节	4 小时
架构设计	审查合约架构、确认模块边界	生成合约架构图、接口定义	2 小时
合约编写	审查关键安全逻辑（重入、权限）	编写全部合约代码（3000 行）	8 小时
测试编写	定义测试策略（安全测试重点）	生成 200+ 测试用例	4 小时
安全扫描	审查扫描报告、判断误报	运行 Slither + Mythril、生成报告	2 小时
漏洞修复	确认修复方案	自动修复发现的问题	3 小时
Gas 优化	确认优化不改变业务逻辑	优化存储布局、减少冗余计算	2 小时
部署脚本	确认部署策略	生成部署脚本 + 验证脚本	1 小时
总计	审查+决策：10 小时	执行：16 小时	26 小时

结果对比

指标	传统方式（纯人工）	OPC 战略级指令	差异
开发耗时	4-6 周	3-4 天	-85%
合约代码量	3,000 行	3,200 行（含额外安全代码）	+7%
测试用例数	80-120 个（人工覆盖不足）	210 个（AI 全面覆盖）	+75%
高危漏洞	2-3 个（人工遗漏）	0 个（AI + 扫描双重检查）	-100%
Gas 消耗（核心操作）	185,000	168,000	-9%
代码注释覆盖率	40%	92%	+130%
开发成本（$50/h）	$8,000-$12,000	$1,300（26h × $50）	-87%

关键发现：Web3 项目的安全约束越明确，AI 的输出质量越高。在翻译式协作中，开发者需要逐行审查每个安全模式——而在战略级指令中，你只需要在 PRD 中声明"使用 ReentrancyGuard"、"Checks-Effects-Interactions 模式"，AI 就会自动在整个项目中一致地应用这些模式。这正是《策略思维》中"承诺机制"的工程化应用——你通过 PRD 向 AI 做出"可信承诺"，AI 也在代码中向你做出"可信承诺" [6]。

关键 Prompt 示例（DeFi 借贷协议）：

你是一个资深 Solidity 安全工程师。请开发一个 DeFi 借贷协议。

## 核心功能
1. 用户可以存入 ERC-20 代币作为抵押品
2. 用户可以根据抵押品价值借出代币（最大 LTV 75%）
3. 当抵押率低于 150% 时触发清算（清算人获得 5% 奖励）
4. 利率模型：基于资金利用率的浮动利率

## 安全约束（绝对不可违反）
- 使用 OpenZeppelin 的 ReentrancyGuard 防止重入攻击
- 所有外部调用采用 Checks-Effects-Interactions 模式
- 使用 Chainlink 喂价，含偏差检查（>5% 则暂停）
- 管理员功能使用 Timelock（48 小时延迟）+ 多签
- 紧急暂停机制（Pausable），任何异常可一键暂停

## 验收标准
- Hardhat 测试全部通过（200+ 用例）
- Slither 静态分析零高危漏洞
- 代码注释覆盖率 > 80%
- Gas 优化：核心操作 < 200,000 gas

## 约束
- 不使用任何未经审计的外部库
- 所有价格计算使用 18 位精度
- 不实现闪电贷功能（V2 再加）
- 先在 Hardhat 本地网络测试，再部署到测试网

## 输出要求
- 完整合约代码（含详细注释）
- 测试套件（200+ 用例）
- 部署脚本（主网 + 测试网）
- 安全扫描报告
- 技术文档（架构图 + 接口说明）

案例三：Web3 DApp 全栈开发——从零构建 NFT 市场

属性	数值
项目类型	NFT 交易市场（类似 OpenSea 精简版）
技术栈	Next.js 14 + Solidity + The Graph + IPFS
前端页面	12 个
智能合约	4 个（Marketplace、NFT、Royalty、Governance）
总代码量	15,000 行
开发耗时	6 天（OPC 模式）
传统团队耗时	6-8 周（3 人团队）

人机分工：

人类：定义产品需求、设计经济模型（手续费比例、版税机制）、审查安全逻辑
AI：编写前端页面、智能合约、子图索引、部署脚本、测试用例

关键 PRD 要素：

NFT 铸造支持 lazy minting（降低创作者 gas 成本）
交易手续费 2.5%，其中 1% 归创作者版税
支持以太坊主网 + Polygon（L2 降低用户成本）
集成 IPFS 存储元数据（去中心化）
子图索引实现实时交易数据查询

执行过程：

阶段	人类做什么	AI 做什么	耗时
需求分析	定义产品功能、经济模型	生成 PRD、竞品分析	3 小时
智能合约	审查安全逻辑	编写 4 个合约（1200 行）	6 小时
子图开发	定义索引实体	编写 subgraph schema + mapping	2 小时
前端开发	审查 UI/UX	编写 12 个页面（8000 行）	16 小时
测试	定义测试策略	生成 150+ 测试用例	4 小时
部署	确认部署策略	生成部署脚本 + 验证	2 小时
总计	审查+决策：12 小时	执行：28 小时	35 小时

结果：6 天完成（含人类审查时间），传统团队需要 6-8 周（3 人）。成本从 $24,000-$32,000 降到 $1,750（35h × $50），节省 93%。

PRD 模板：战略级指令的标准格式

一个高质量的 PRD 应包含以下要素，确保 AI 能自主执行而不需要人类逐步指导：

PRD 六要素框架

PRD 要素	说明	示例	常见错误
项目背景	技术栈、当前状态、痛点	"Vue 2 + Webpack，首屏 4.2s"	只说"重构项目"，不给背景
迁移目标	明确的、可衡量的目标	"Vue 3 + Vite，首屏 < 2s"	"优化性能"（无法衡量）
验收标准	量化的、可自动验证的条件	"Lighthouse > 90，测试全通过"	"确保功能正常"（无法验证）
约束条件	不可改变的限制	"API 接口不变，渐进式迁移"	没有约束（AI 可能过度改动）
风险提示	已知的坑和注意事项	"Vuex → Pinia 需要手动调整"	假设 AI 什么都知道
输出要求	AI 需要交付的产物	"迁移报告 + 变更清单"	不指定输出格式

完整 PRD 模板示例：Web3 DeFi 协议开发

以下是一个真实的 Web3 项目 PRD 模板，可以直接复制修改后使用：

markdown

# PRD：DeFi 借贷协议 V1 开发

## 1. 项目背景
- 目标：开发一个去中心化借贷协议，支持多资产抵押借贷
- 当前状态：从零开始，无遗留代码
- 参考协议：Aave V3（精简版，仅核心借贷功能）
- 目标用户：DeFi 用户，需要抵押资产借出稳定币

## 2. 技术栈
- 智能合约：Solidity 0.8.20 + OpenZeppelin 4.9
- 开发框架：Hardhat + TypeScript
- 前端：Next.js 14 + ethers.js v6 + wagmi
- 索引：The Graph（子图）
- 预言机：Chainlink Price Feeds
- 部署网络：以太坊主网 + Arbitrum

## 3. 核心功能（按优先级排序）
### P0（必须实现）
- [ ] 存入 ERC-20 代币作为抵押品
- [ ] 根据抵押品价值借出代币（最大 LTV 75%）
- [ ] 浮动利率模型（基于资金利用率）
- [ ] 清算机制（抵押率 < 150% 触发，清算奖励 5%）
- [ ] Chainlink 预言机集成（价格偏差 > 5% 则暂停）

### P1（应该实现）
- [ ] 多资产支持（ETH, USDC, DAI, WBTC）
- [ ] 紧急暂停机制
- [ ] 管理员 Timelock（48 小时延迟）

### P2（可以延后）
- [ ] 闪电贷功能（V2）
- [ ] 治理代币（V2）
- [ ] 跨链借贷（V3）

## 4. 安全约束（绝对不可违反）
- 使用 ReentrancyGuard 防止重入攻击
- 所有外部调用采用 Checks-Effects-Interactions 模式
- 价格计算使用 18 位精度，中间结果使用 36 位精度
- 管理员功能使用 Timelock + 多签（3/5）
- 紧急暂停功能，任何异常可一键暂停所有操作

## 5. 验收标准
- [ ] Hardhat 测试全部通过（目标 200+ 用例）
- [ ] Slither 静态分析零高危/中危漏洞
- [ ] Mythril 符号执行通过
- [ ] 代码注释覆盖率 > 80%（NatSpec 格式）
- [ ] Gas 优化：核心操作 < 200,000 gas
- [ ] 前端可正常连接钱包并执行所有操作
- [ ] 测试网部署并运行 72 小时无异常

## 6. 约束条件
- 不使用任何未经审计的外部库
- 不实现闪电贷功能（V2 再加）
- 先在 Hardhat 本地网络测试，再部署到 Sepolia 测试网
- 合约大小不超过 24KB（以太坊限制）

## 7. 交付产物
- [ ] 完整合约代码（含详细注释）
- [ ] 测试套件（200+ 用例）
- [ ] 部署脚本（主网 + 测试网）
- [ ] 安全扫描报告
- [ ] 技术文档（架构图 + 接口说明）
- [ ] Gas 消耗报告

关键区别：翻译式指令告诉 AI "把 Button.vue 的 props 从 Options API 改为 Composition API"；战略级指令告诉 AI "把这个项目迁移到 Vue 3，首屏 < 2 秒，其他不变"。前者需要你理解每一行代码，后者只需要你理解业务目标。

PRD 质量检查清单

写完 PRD 后，用以下清单自检：

检查项	通过标准	常见问题
目标可衡量	有具体数字（< 2s, > 90 分）	"优化性能"、"提升体验"
约束明确	列出了"不能做什么"	只说"做什么"，没说"不能做什么"
验收可自动化	AI 可以自行运行测试验证	"人工检查一下"
技术栈完整	列出了所有依赖和版本	"用 React"（哪个版本？什么状态管理？）
风险预判	列出了已知的坑和注意事项	假设 AI 不会犯错
分阶段	大任务拆成 3-5 个里程碑	一次性交付所有功能

Web2 vs Web3 PRD 的关键差异

维度	Web2 PRD	Web3 PRD
安全约束	建议性（可以后补）	强制性（必须前置）
验收标准	功能测试为主	安全测试 + 功能测试
错误容忍度	高（可以热修复）	零（上线不可篡改）
经济模型	不需要	必须明确（手续费、激励、通胀）
审计要求	可选	必须（至少静态分析）
部署策略	随时部署	测试网运行 72h+ 才能主网

三个案例的综合对比

维度	案例一：Vue 迁移	案例二：DeFi 借贷协议	案例三：NFT 市场
项目类型	Web2 前端迁移	Web3 智能合约	Web3 全栈 DApp
代码规模	50,000 行	3,000 行	15,000 行
开发耗时	4 天	3-4 天	6 天
传统耗时	3-4 周	4-6 周	6-8 周
效率提升	5x	7x	6x
成本节省	78%	84%	93%
PRD 复杂度	中	高（安全约束）	高（全栈+安全）
人类审查占比	15%	30%	25%

核心发现：Web3 项目的效率提升倍数反而更高（7x vs 5x），原因是 Web3 的安全约束在 PRD 中声明后，AI 的执行一致性远超人工——人类容易在疲劳时遗漏安全模式，AI 不会。这正是工程化协同在高风险领域的独特价值。

成本对比分析

成本项	翻译式	战略级指令	差异
人力时间	160 小时（4 周）	32 小时（4 天）	-80%
时薪成本（$50/h）	$8,000	$1,600	-80%
API 费用	$50-100	$100-200	+100%
返工成本	$500-1000（Bug 修复）	$100-200（极少）	-80%
总成本	$8,550-$9,100	$1,800-$2,000	-78%

三个案例的综合成本对比：

案例	传统方式成本	OPC 战略级指令成本	节省金额	节省比例
Vue 迁移（5 万行）	$8,550-$9,100	$1,800-$2,000	$6,750-$7,100	-78%
DeFi 借贷协议	$8,000-$12,000	$1,300	$6,700-$10,700	-84%
NFT 市场全栈	$24,000-$32,000（3 人 × 6-8 周）	$2,400（48h × $50）	$21,600-$29,600	-90%

ROI 分析：如果你是一个 OPC 开发者，用战略级指令模式接单，每个项目的利润率从传统的 30-40% 提升到 75-85%。这意味着同样的接单量，你的收入可以翻 2-3 倍。这正是工程化协同的商业价值——不是"省时间"这么简单，而是改变了整个商业模型的利润率结构。

Web3 工程化协同的特殊挑战

Web2 开发中，PRD 的验收标准主要是"功能正确 + 性能达标"。但 Web3 开发增加了一个维度——安全即功能。一个"功能正确"但有安全漏洞的智能合约，比一个"功能不完整"的合约更危险，因为它可能直接导致资金损失。

Web3 PRD 的安全约束清单

在 Web3 项目的 PRD 中，以下安全约束必须显式声明，不能依赖 AI "自行理解"：

安全类别	必须声明的约束	不声明的后果
重入攻击	"使用 ReentrancyGuard，所有外部调用用 CEI 模式"	AI 可能写出可重入的函数，导致资金被重复提取
整数溢出	"关键路径使用 SafeMath 或 Solidity 0.8+ 内置检查"	AI 可能忽略边界条件，导致计算错误
权限控制	"管理功能使用 Timelock + 多签，不使用单一 EOA"	AI 可能给单一地址过大的权限
预言机安全	"价格源使用 Chainlink，偏差 > 5% 则暂停"	AI 可能使用单一价格源，容易被操纵
前端运行	"大额操作使用私有交易池或 Flashbots Protect"	AI 可能忽略 MEV 前端运行风险
紧急暂停	"所有核心功能可被紧急暂停，暂停后资金可提取"	AI 可能设计出"暂停后资金锁死"的合约

Web3 工程化协同的人机分工

关键数据：在 Web3 项目中，安全约束前置（在 PRD 中明确声明）vs 后置（开发完成后再补安全措施）的对比：

维度	安全约束前置	安全约束后置	差异
高危漏洞数	0-1 个	3-5 个	-80%
审计修复时间	2-3 天	1-2 周	-70%
审计费用	$5,000-$10,000	$15,000-$30,000	-60%
主网部署后事故率	< 1%	5-10%	-90%

这组数据说明了一个核心道理：在 Web3 中，PRD 的安全约束不是"可选的附加项"，而是"决定项目生死的核心要素"。

Web3 vs Web2 工程化协同的效率差异

维度	Web2 项目	Web3 项目	差异原因
PRD 编写时间	1-2 小时	3-4 小时	Web3 需要额外的安全约束
AI 一次通过率	65%	45%	Web3 的安全约束增加了复杂度
人类审查时间占比	15%	30%	Web3 需要更多安全审查
返工率	8%	15%	Web3 的安全问题需要更多修复
总项目耗时倍数	1x（基准）	1.5-2x	Web3 的安全成本

但：Web3 项目的单价通常是 Web2 的 3-10 倍（因为安全溢价），所以 OPC 的利润率反而更高。一个安全可靠的 DeFi 协议审计服务收费 $5,000-$50,000，而一个 Web2 网站开发可能只收 $2,000-$5,000。

趋势预判（未来 1-3 年）

技术演进方向

趋势	当前状态（2025）	2027 年预判	对 OPC 的影响
PRD 驱动开发	手动写 PRD + AI 执行	AI 自动生成 PRD + 执行	从"写 PRD"到"描述想法"
多 Agent 协作	单 Agent 串行执行	多 Agent 并行协作	一个 OPC = 一个团队
自动化测试	AI 生成测试用例	AI 自主设计测试策略	测试工程师角色消失
持续集成	手动配置 CI/CD	AI 自动配置和优化	DevOps 自动化
代码审查	人类逐行审查	AI 预审 + 人类终审	审查效率 10x
智能合约审计	人工审计 + 静态分析	AI 自动形式化验证	审计成本降低 80%
跨链开发	手动适配多链	AI 自动多链适配	一套代码多链部署

ThoughtWorks 将 Spec-driven development 和 GitHub Spec-Kit 列为关键技术 [5]——用规范文档驱动 AI 生成代码，正是"战略级指令"的工程化实现。

工程化协同的三个演进阶段

每个阶段的数据预测：

阶段	人类介入时间占比	PRD 通过率	单项目耗时	OPC 可并行项目数
阶段一（当前）	40%	32%（一次通过）	4 天	1-2 个
阶段二（2026-2027）	20%	65%	1-2 天	3-5 个
阶段三（2028+）	5%	90%	数小时	10+ 个

关键拐点：当 AI 的 PRD 一次通过率超过 80% 时，OPC 模式将从"一个项目一个项目做"变成"同时管理多个项目"——这才是真正的"一人即帝国"。

角色变化趋势

协同比喻的进化：

阶段	时间	人类角色	AI 角色	类比	核心技能
逐步指令	2023 前	翻译员	打字员	经理坐旁边指手画脚	Prompt 编写
PRD 驱动	2024-2026	产品经理	全栈工程师	经理写需求文档	PRD 写作、需求分析
架构决策	2026-2028	架构师	开发团队	CTO 定方向	系统设计、技术选型
产品定义	2028+	CEO	AI 公司	创始人描述愿景	商业思维、战略规划

每个阶段的能力要求变化：

能力维度	阶段一（当前）	阶段二（2026）	阶段三（2028+）
Prompt 工程	核心技能	基础技能	不需要
PRD 写作	进阶技能	核心技能	基础技能
架构设计	高级技能	核心技能	核心技能
商业思维	锦上添花	重要技能	核心技能
安全意识	Web3 专属	通用技能	通用技能
博弈论思维	不需要	进阶技能	核心技能

这正是《超预测》中"校准"概念的工程化映射 [8]——你需要持续校准自己的能力组合，确保它与当前阶段的需求匹配。如果你在 2026 年还在靠"Prompt 工程"吃饭，就像 2025 年还在靠"会用 Google"吃饭一样——这项技能已经从"核心竞争力"变成了"基础设施"。

需要提前准备的能力

1. PRD 写作能力（最优先）

PRD 写作是工程化协同的"第一公民"。你需要掌握：

需求结构化：把模糊的业务需求转化为可执行的技术需求
约束表达：清晰定义"不能做什么"（比"做什么"更重要）
验收标准量化：用数字而非形容词描述成功标准
风险预判：提前识别 AI 可能遇到的坑，在 PRD 中给出提示

练习方法：每周写一份 PRD，交给 AI 执行，记录一次通过率。目标：3 个月内将一次通过率从 30% 提升到 60%。

2. 架构设计能力

架构设计是人类在 AI 时代最不可替代的能力：

系统架构图：用 Mermaid/PlantUML 画出模块关系、数据流、依赖图
技术选型：在多个技术方案中做出权衡（性能 vs 开发速度 vs 维护成本）
模块边界：定义清晰的接口，让 AI 可以独立开发每个模块
Web3 特殊架构：链上 vs 链下、存储层选择（IPFS/Arweave）、预言机方案

3. 安全意识（Web3 必备）

Web3 开发中，安全不是"可选功能"，而是"生存条件"：

重入攻击：理解 Checks-Effects-Interactions 模式
整数溢出：理解 Solidity 0.8+ 的内置保护和边界情况
权限控制：理解 Ownable、AccessControl、Timelock 的区别和适用场景
预言机安全：理解 Chainlink 的偏差检查、TWAP 防操纵机制

4. 博弈论思维

从《策略思维》中学到的核心思维方式 [6]：

纳什均衡：理解为什么"所有人都做最优选择"可能导致"所有人都更差"
承诺机制：用智能合约实现可信承诺（锁仓、Timelock）
混合策略：在不确定环境中随机化策略，避免被预测
信号传递：通过高成本行为传递质量信号（审计、锁仓、开源）

5. 预测与校准能力

从《超预测》中学到的核心思维方式 [8]：

贝叶斯更新：每获得新信息就微调判断，而不是固守初始结论
费米估计：把复杂问题分解为可估计的子问题
校准训练：定期检验自己的判断准确率，修正系统性偏差
狐狸型思维：跨学科整合信息，不依赖单一模型

PRD 写作的常见错误

错误类型	错误示例	正确示例	影响
目标模糊	"优化性能"	"P99 响应时间 < 200ms"	AI 不知道优化到什么程度
缺少约束	"迁移到 Vue 3"	"迁移 Vue 3，API 不变，渐进式"	AI 可能过度改动
无验收标准	"确保功能正常"	"Lighthouse > 90，测试全通过"	无法客观判断是否完成
过度细节	逐行描述代码修改	描述业务目标和验收条件	变回翻译式协作
缺少上下文	"重构这个模块"	"Vue 2.7 + Webpack，50 个组件..."	AI 缺乏必要信息
忽略安全	"开发借贷协议"	"开发借贷协议，安全约束：..."	Web3 中直接导致资金损失
无分阶段	"一次性完成所有功能"	"分 3 阶段：核心→扩展→优化"	大任务 AI 容易迷失方向
无风险提示	"集成 Chainlink"	"集成 Chainlink，注意偏差检查"	AI 可能忽略关键细节

Web3 PRD 的三个致命错误：

致命错误一：不声明安全约束

错误 PRD："开发一个 DeFi 借贷协议，支持存入和借出功能。"
正确 PRD："开发 DeFi 借贷协议。安全约束：ReentrancyGuard + CEI 模式 + 
         Chainlink 偏差检查 + Timelock 多签管理 + 紧急暂停机制。"

不声明安全约束，AI 可能写出"功能正确但有漏洞"的代码——这在 Web3 中比"功能不完整"更危险。

致命错误二：不指定精度要求

错误 PRD："计算用户可借金额。"
正确 PRD："计算用户可借金额。精度要求：使用 18 位小数（1e18），
         中间计算使用 36 位精度防止舍入误差，最终结果向下取整。"

智能合约中的精度错误可能导致用户借出超过抵押品价值的资产——直接经济损失。

致命错误三：不定义边界条件

错误 PRD："当抵押率低于 150% 时触发清算。"
正确 PRD："当抵押率低于 150% 时触发清算。边界条件：
         - 抵押率为 0%（无抵押品）→ 禁止借出
         - 抵押率为 149.9% → 触发清算
         - 抵押率为 150.1% → 不触发清算
         - 清算时抵押品价值波动 > 10% → 取消本次清算
         - 清算人奖励 = 清算金额 × 5%，上限 10 ETH"

不定义边界条件，AI 可能在极端情况下做出错误判断——而链上的"极端情况"正是黑客攻击的入口。

核心原则：PRD 是写给 AI 的"需求文档"，不是写给人的"技术文档"。AI 需要明确的目标、清晰的约束、可验证的标准——而不是"你看着办"。

战略级指令的进阶技巧

技巧	说明	示例
分阶段交付	大任务拆成 3-5 个里程碑	"第一阶段：数据库迁移"
约束优先	先说不能做什么	"不要改变 API 接口"
示例驱动	给一个期望输出的示例	"参考这个组件的写法"
渐进式验证	每个阶段验收后再继续	"完成数据库后停下来"
风险提示	提前告诉 AI 可能的坑	"注意 Vuex → Pinia 的差异"
角色设定	为 AI 设定专业角色	"你是资深 Solidity 安全工程师"
反例提供	告诉 AI 不要做什么	"不要用 any 类型，不要用 console.log"
参考代码	提供风格参考	"参考 src/utils/ 下的代码风格"

进阶心得：战略级指令不是一次性的——复杂项目需要多轮对话，每轮聚焦一个里程碑。关键是让 AI 在每轮之间保持上下文连贯。

高级技巧：博弈论驱动的 PRD 设计

将《策略思维》中的博弈论概念 [6] 应用到 PRD 设计中，可以显著提升 AI 的执行质量：

技巧一：约束即"可信承诺"

在博弈论中，可信承诺是最有力的策略工具。在 PRD 中，约束条件就是你对 AI 的"可信承诺"——你告诉 AI "这些边界不可逾越"，AI 就会在这些边界内寻找最优解。

低效 PRD："帮我优化这个 API 的性能。" 高效 PRD："优化 API 响应时间。约束：不能改变数据库结构、不能引入缓存层、不能修改外部 API 调用格式。验收标准：P99 < 200ms。"

后者通过约束缩小了 AI 的"策略空间"，反而让 AI 更容易找到最优解——就像在迷宫中画出不可通行的墙壁，反而让你更快找到出口。

技巧二：验收标准即"激励机制"

博弈论告诉我们，激励机制决定了参与者的行为。在 PRD 中，验收标准就是给 AI 的"激励机制"——AI 会朝着满足验收标准的方向努力。

关键洞察：验收标准的质量直接决定 AI 输出的质量。如果你的验收标准是"确保功能正常"（模糊），AI 可能给出一个勉强能跑的方案；如果你的验收标准是"200+ 测试用例全部通过、Slither 零高危漏洞、Gas < 200k"（精确），AI 会给出一个高质量的方案。

技巧三：分阶段即"重复博弈"

《策略思维》指出，重复博弈中更容易产生合作 [6]。将大项目拆成多个阶段，每个阶段都是一次"博弈"——你审查 AI 的输出，AI 根据你的反馈调整策略。这种"迭代博弈"比"一次性博弈"更容易达成高质量的合作。

实践建议：

每个阶段聚焦一个独立功能模块
每个阶段结束后审查并提供反馈
下一阶段的 PRD 基于上一阶段的输出调整
保持全局视角，确保各阶段的接口一致

高级技巧：超级预测者式的需求分析

将《超预测》中的预测方法论 [8] 应用到需求分析中：

费米估计式需求拆解

面对一个复杂需求时，用费米估计的方法将其分解：

原始需求："开发一个支持百万用户的社交平台。"

费米分解：

百万用户的并发量是多少？→ 假设 10% 活跃率 → 10 万日活 → 峰值 1 万 QPS
1 万 QPS 需要什么架构？→ 至少 3 台应用服务器 + 读写分离数据库
存储需求？→ 每用户 10MB → 10TB 存储
带宽需求？→ 每用户每天 5MB 流量 → 500TB/天

将这些分解结果写入 PRD，AI 就能基于具体数字做出合理的架构决策。

校准式 PRD 迭代

每次 PRD 执行后，记录：

PRD 中哪些描述 AI 理解正确？
PRD 中哪些描述 AI 理解偏差？
偏差的原因是什么？（描述模糊、缺少上下文、技术细节不足）

建立自己的"PRD 校准曲线"——哪种写法更容易让 AI 一次通过，哪种写法容易导致返工。经过 10-20 次迭代，你就能形成自己的"PRD 直觉"。

工程化协同的实战工具箱

PRD 编写检查流程

每次写完 PRD 后，按以下流程检查：

常见反模式（Anti-patterns）

反模式	表现	后果	正确做法
微管理型	每个函数都指定具体实现	变回翻译式协作，效率低	只描述目标和约束
放任型	"你看着办"	AI 可能做出完全不同的选择	提供验收标准和约束
完美主义型	PRD 写了 50 页，覆盖所有边角	写 PRD 的时间比直接做还长	PRD 控制在 2-5 页
恐惧型	AI 写完后逐行审查	浪费了 AI 的效率优势	只审查关键逻辑和安全点
跳跃型	不分阶段，一次性交付	AI 容易迷失方向	分 3-5 个里程碑
忽略反馈型	不根据 AI 输出调整 PRD	同样的错误反复出现	贝叶斯式迭代更新 PRD

CLI 工具推荐

工具	用途	与工程化协同的关系
Claude Code CLI	全栈自主开发	战略级指令的主要执行引擎
Cursor	IDE 内 AI 辅助	适合需要频繁交互的场景
GitHub Copilot	代码补全	适合翻译式协作，不适合战略级
Hardhat	Solidity 开发框架	Web3 项目的测试和部署
Slither	Solidity 静态分析	PRD 验收标准的自动化检查
Foundry	Solidity 测试框架	高性能的合约测试

效率倍增器：CLAUDE.md 文件

在项目根目录创建 CLAUDE.md 文件，记录项目的编码规范、架构决策和常见约束。这个文件会被 Claude Code CLI 自动读取，相当于给 AI 一份"项目手册"——每次对话都不需要重复说明基础信息。

CLAUDE.md 示例：

markdown

# 项目规范

## 技术栈
- Solidity 0.8.20 + OpenZeppelin 4.9
- Hardhat + TypeScript
- 测试框架：Hardhat + Chai

## 安全规范
- 所有外部调用使用 ReentrancyGuard
- 管理功能使用 Timelock + 多签
- 价格计算使用 18 位精度
- 所有合约必须有 NatSpec 注释

## 代码风格
- 函数命名：camelCase
- 常量命名：UPPER_SNAKE_CASE
- 每个函数必须有 NatSpec 注释
- 测试用例命名：test_shouldXXX_whenYYY

## 验收标准
- 测试覆盖率 > 90%
- Slither 零高危漏洞
- Gas 优化：核心操作 < 200k

有了这个文件，你的 PRD 就不需要每次都重复这些基础规范——AI 会自动遵守 CLAUDE.md 中的规则。

核心洞察

底线认知

工程化协同的本质是角色升级——从"写代码的人"变成"定义需求的人"。OPC 不需要写每一行代码，但需要知道什么代码应该被写、怎么验收、如何判断质量。

2025 年，84% 的开发者在用 AI [1]，但只有少数人能用"战略级指令"驱动 AI。会写 PRD 的人，将取代会写代码的人。

关键数据

翻译式协作的人类管理时间占比：80%（描述怎么做）
战略级指令的人类管理时间占比：15%（定义做什么 + 验收）
采用 PRD 驱动的项目一次通过率提升：32% → 71%
Web3 项目中安全约束前置 vs 后置的漏洞率差异：-85%

认知陷阱

陷阱一："AI 写的代码不靠谱，我得每行都审查。"——如果你需要审查每一行，问题不在 AI，在你的 PRD 没写清楚。好的 PRD 让 AI 的输出"几乎不需要审查"。

陷阱二："PRD 太浪费时间，直接告诉 AI 做什么更快。"——对于 100 行的小任务，确实如此。但对于 1 万行以上的项目，PRD 的投入产出比是 1:8（花 1 小时写 PRD，节省 8 小时的返工）。

陷阱三："Web3 太危险了，不能让 AI 自主写智能合约。"——恰恰相反，Web3 的高风险特性意味着你更需要用 PRD 来约束 AI。翻译式协作中，你可能遗漏某个安全模式；PRD 驱动中，你在 PRD 中声明"必须使用 ReentrancyGuard"，AI 会在整个项目中一致地应用它。

行动指南

今天就能做的事：

找一个你正在做的小项目（< 1000 行），用 PRD 驱动方式重做一遍，对比效率
在项目根目录创建 CLAUDE.md，记录编码规范和安全约束
把你的 PRD 模板保存为 .md 文件，下次直接复制修改

本周要做的事：

用战略级指令完成一个中型任务（1000-5000 行），记录耗时和质量
建立"PRD 校准日志"，记录每次 PRD 的一次通过率

本月要做的事：

用战略级指令完成一个完整项目，体验全流程
将 PRD 一次通过率提升到 50% 以上
开始学习 Web3 安全约束，为 Web3 项目做准备

从"会写代码"到"会写 PRD"的能力迁移路径

每个阶段的关键指标：

阶段	PRD 一次通过率	人类干预次数	项目耗时降低	感受
第一周	10%	高	无	"PRD 没用"
第二周	25%	中	20%	"有点效果"
第三周	40%	中低	40%	"确实快了"
第四周	50%	低	60%	"回不去了"
第二个月	60%	很低	75%	"这才是正确的协作方式"
第三个月	70%+	极低	80%+	"一人即帝国"

参考与延伸

[1] Stack Overflow. "2025 Developer Survey"（2025-06）— 84% 开发者使用 AI 工具、46% 不信任 AI 输出准确性。正文引用：传统模式痛点中"开发者信任度"数据。

[2] McKinsey. "The economic potential of generative AI"（2023-06）— AI 对软件开发效率的提升评估，每年 2.6-4.4 万亿美元增量。正文引用：OPC 模式中"AI 生产力潜力"论证。

[3] Anthropic. "SWE-bench Verified Results"（2025-03）— Claude 在 SWE-bench 上通过率 49%，证明 AI 可独立解决复杂工程问题。正文引用：OPC 模式中"AI 能力论证"。

[4] Cognition. "Devin: AI Software Engineer"（2024-03）— 首个 AI 软件工程师，SWE-bench 通过率 13.86%。正文引用：OPC 模式中"AI 工程能力"论证。

[5] ThoughtWorks. "Technology Radar Vol.34"（2026-04）— Spec-driven development、Agent Skills、GitHub Spec-Kit 等工程化 AI 协作工具评估。正文引用：趋势预判中"PRD 驱动开发"趋势。

[6] Dixit, A. & Nalebuff, B. "策略思维"（2008）— 博弈论通俗入门，核心概念：纳什均衡、可信承诺、混合策略。正文引用：OPC 模式中"博弈论视角"、PRD 设计中"约束即承诺"。

[7] JetBrains. "State of Developer Ecosystem 2025"（2025-09）— 67% 开发者仍采用翻译式协作，18% 使用 PRD 驱动模式。正文引用：传统模式痛点中"协作方式分布"数据。

[8] Tetlock, P. "超预测：预测的艺术与科学"（2015）— 20 年研究证明预测可训练，核心概念：贝叶斯更新、校准、费米估计、狐狸型思维。正文引用：OPC 模式中"PRD 即预测"、趋势预判中"能力校准"。

方案跃迁指引

下一步去哪

完成本章后，根据你的方案选择：

方案	下一步	预计时长
方案1：远程就业	4.1 自动化测试哨兵	3h
方案2：开公司	4.1 自动化测试哨兵	3h
方案3：量化交易	9.1 Web3 架构	3h

方案 1/2 继续完善自动化能力，方案 3 开始进入 Web3 领域。

2.2 工程化协同 ​

传统模式：痛点与瓶颈 ​

"翻译式"协作的效率陷阱 ​

装修房子的比喻：你不会告诉工人每颗钉子钉在哪里 ​

为什么"翻译式"不可扩展 ​

OPC 模式：重新定义 ​

核心理念 ​

博弈论视角：为什么"战略级指令"是更优策略 ​

超级预测者思维：写 PRD 就是在做预测 ​

人机分工矩阵 ​

战略级指令 vs 翻译式指令 ​

效率对比 ​

执行计划 ​

每日 SOP ​

每周复盘 ​

进度尺子 ​

实操案例 ​

案例一：重构一个 5 万行 Vue 项目，首屏加载提速 50% ​

场景详情 ​

两种方式的执行对比 ​

执行过程分解 ​

最终结果对比 ​

关键 Prompt 示例（Vue 迁移） ​

案例二：Web3 智能合约开发——用 OPC 模式构建 DeFi 借贷协议 ​

场景详情 ​

战略级指令 PRD ​

执行过程与人机分工 ​

结果对比 ​

案例三：Web3 DApp 全栈开发——从零构建 NFT 市场 ​

PRD 模板：战略级指令的标准格式 ​

PRD 六要素框架 ​

完整 PRD 模板示例：Web3 DeFi 协议开发 ​

PRD 质量检查清单 ​

Web2 vs Web3 PRD 的关键差异 ​

三个案例的综合对比 ​

成本对比分析 ​

Web3 工程化协同的特殊挑战 ​

Web3 PRD 的安全约束清单 ​

Web3 工程化协同的人机分工 ​

Web3 vs Web2 工程化协同的效率差异 ​

趋势预判（未来 1-3 年） ​

技术演进方向 ​

工程化协同的三个演进阶段 ​

角色变化趋势 ​

需要提前准备的能力 ​

1. PRD 写作能力（最优先） ​

2. 架构设计能力 ​

3. 安全意识（Web3 必备） ​

4. 博弈论思维 ​

5. 预测与校准能力 ​

PRD 写作的常见错误 ​

战略级指令的进阶技巧 ​

高级技巧：博弈论驱动的 PRD 设计 ​

技巧一：约束即"可信承诺" ​

技巧二：验收标准即"激励机制" ​

技巧三：分阶段即"重复博弈" ​

高级技巧：超级预测者式的需求分析 ​

费米估计式需求拆解 ​

校准式 PRD 迭代 ​

工程化协同的实战工具箱 ​

PRD 编写检查流程 ​

常见反模式（Anti-patterns） ​

CLI 工具推荐 ​

效率倍增器：CLAUDE.md 文件 ​

核心洞察 ​

从"会写代码"到"会写 PRD"的能力迁移路径 ​

参考与延伸 ​

方案跃迁指引 ​

下一步去哪 ​

学习路径 ​

2.2 工程化协同

传统模式：痛点与瓶颈

"翻译式"协作的效率陷阱

装修房子的比喻：你不会告诉工人每颗钉子钉在哪里

为什么"翻译式"不可扩展

OPC 模式：重新定义

核心理念

博弈论视角：为什么"战略级指令"是更优策略

超级预测者思维：写 PRD 就是在做预测

人机分工矩阵

战略级指令 vs 翻译式指令

效率对比

执行计划

每日 SOP

每周复盘

进度尺子

实操案例

案例一：重构一个 5 万行 Vue 项目，首屏加载提速 50%

场景详情

两种方式的执行对比

执行过程分解

最终结果对比

关键 Prompt 示例（Vue 迁移）

案例二：Web3 智能合约开发——用 OPC 模式构建 DeFi 借贷协议

场景详情

战略级指令 PRD

执行过程与人机分工

结果对比

案例三：Web3 DApp 全栈开发——从零构建 NFT 市场

PRD 模板：战略级指令的标准格式

PRD 六要素框架

完整 PRD 模板示例：Web3 DeFi 协议开发

PRD 质量检查清单

Web2 vs Web3 PRD 的关键差异

三个案例的综合对比

成本对比分析

Web3 工程化协同的特殊挑战

Web3 PRD 的安全约束清单

Web3 工程化协同的人机分工

Web3 vs Web2 工程化协同的效率差异

趋势预判（未来 1-3 年）

技术演进方向

工程化协同的三个演进阶段

角色变化趋势

需要提前准备的能力

1. PRD 写作能力（最优先）

2. 架构设计能力

3. 安全意识（Web3 必备）

4. 博弈论思维

5. 预测与校准能力

PRD 写作的常见错误

战略级指令的进阶技巧

高级技巧：博弈论驱动的 PRD 设计

技巧一：约束即"可信承诺"

技巧二：验收标准即"激励机制"

技巧三：分阶段即"重复博弈"

高级技巧：超级预测者式的需求分析

费米估计式需求拆解

校准式 PRD 迭代

工程化协同的实战工具箱

PRD 编写检查流程

常见反模式（Anti-patterns）

CLI 工具推荐

效率倍增器：CLAUDE.md 文件

核心洞察

从"会写代码"到"会写 PRD"的能力迁移路径

参考与延伸

方案跃迁指引

下一步去哪

学习路径