不止教按Tab补全，而是让Codex像工程师一样读取仓库、修改文件、运行测试、通过审查，直完成可交付的工程任务。 ·系统讲透“Harness工程” 提示词再漂亮，AI看不懂代码也是徒劳。专章拆解代码库结构、依赖关系、项目约定，并教会你撰写AGENTS.md，为每次协作建立稳定上下文。 ·场景实战，每章解决一个真实痛 告别功能罗列，围绕手老代码、修Bug+测试、跨前后端发、PR/Review/CI/CD等真实场景组织，让你学完就知道“能解决什么问题”。
售 价：¥
纸质售价：¥49.80购买纸书
6.5
温馨提示：数字商品不支持退换货，不提供源文件，不支持导出打印
为你推荐
内 容 提 要
推荐语
前言
第1章 Codex是聊天机器人，更是交付工具
1.1 AI编程工具的三次演进：从代码补全到智能体
1.1.1 第一种范式：代码补全
1.1.2 第二种范式：对话式助手
1.1.3 第三种范式：智能体
1.2 为什么Codex是软件工程交付工具
1.2.1 交付工具的5个核心特征
1.2.2 和传统CI/CD的关系
1.2.3 交付质量必须可观察
1.2.4 Codex不完美，但方向不同
1.3 从“会写代码”到“能交付任务”：心智模型的转变
1.3.1 从“问答”到“委托”
1.3.2 任务描述的质量决定产出质量
1.3.3 从“一次性输出”到“迭代式协作”
1.3.4 搭建Harness，而不是编写剧本
1.3.5 信任，但按风险分级验证
1.4 规则优先于“更聪明”：工程视角下的 Codex 使用哲学
1.4.1 项目规则让协作可重复
1.4.2 把反复出现的偏差沉淀为系统约束
1.4.3 人类仍负责目标选择、风险判断与接受标准
本章小结
第2章 AI编程的最小原理——知道边界在哪里
2.1 大语言模型为什么能处理代码
2.2 Codex完成任务时依赖什么
2.2.1 上下文决定Codex此刻能看到什么
2.2.2 文件读取和检索帮助Codex补足项目背景
2.2.3 执行反馈让生成进入工程闭环
2.2.4 能力再强，也不能替代正确的上下文
2.3 第一条边界：信息永远不完整
2.3.1 项目全貌不会自动进入当前任务
2.3.2 最容易缺失的是代码没有明示的关系
2.3.3 信息会在长任务中逐渐变形
2.3.4 项目结构决定上下文的质量
2.4 第二条边界：Codex会犯三类工程错误
2.4.1 幻觉：不知道怎么写，却写得很像
2.4.2 漏改：局部正确，整体不完整
2.4.3 误判：代码没错，决策不对
2.5 从边界意识到协作方法
本章小结
第3章 第一次任务：跑通一条闭环
3.1 安装与登录：先把入口跑通
3.1.1 安装Codex CLI
3.1.2 登录方式：ChatGPT账号或者OpenAI API Key
3.2 任务入口选择：本地执行，还是交给云端做
3.3 一次完整任务的执行流程
3.3.1 五步闭环概览
3.3.2 实战：一个最小变更的完整走查
3.3.3 为什么不能跳过验证
3.3.4 当执行不顺利时怎么应对
3.4 模型选择
3.4.1 Codex模型的三个层级与选择策略
3.4.2 成本与速度的实践指南
3.5 安全边界：哪些任务不应交给Codex
3.5.1 五类高风险任务
3.5.2 分级信任原则
3.6 可复用的工作流
3.6.1 三步法框架
3.6.2 从手工到自动化
本章小结
第4章 Codex的任务地图
4.1 IDE、CLI、App、Web 各自做什么
4.1.1 IDE：离当前文件最近的入口
4.1.2 CLI：本地执行、验证和试错的主战场
4.1.3 App：多任务工作台，而不是更花哨的聊天框
4.1.4 Web：远程环境和异步协作入口
4.1.5 入口如何衔接
4.2 Free、Plus、Pro、Business、Enterprise版本分别适合哪类用户
4.2.1 不要先看价格，先看四类差异
4.2.2 按人群选，比按功能选更实用
4.2.3 一个够用的选型顺序
4.3 手机入口：移动值守与生态桥接层
4.3.1 生态桥接层解决的是“连通性”和“编排”
4.3.2 什么时候值得上手机端和桥接层
4.4 哪些任务适合放在本地，哪些任务适合放在云端
4.4.1 本地与云端的差异，不只是命令在哪里执行
4.4.2 任务能否切面，取决于不确定性是否已经收敛
4.4.3 切换到云端前，先完成任务交接
4.5 Review、Automation、Worktree 的角色
4.5.1 Review：质量闸门，也是第二观察者
4.5.2 Automation：把例行动作变成后台节奏
4.5.3 Worktree：并行隔离的基础设施
4.5.4 把三者放回同一工作流
4.6 任务地图的边界：不是所有的任务都适合直接委派
本章小结
第5章 第一个可复用工作流：在emotional_chat项目中稳定复用
5.1 进入emotional_chat项目前的最小确认
5.1.1 先确认主入口和工作目录
5.1.2 先只读跑通，再允许修改
5.1.3 把默认信息分为三层
5.2 让仓库支撑Agent：readiness、脚本与局部验证
5.2.1 仓库readiness不关乎美观，而关乎可执行性
5.2.2 先选局部验证，再扩大工作面
5.2.3 常见失败，先归因再加码
5.3 走完整条链路：一次最小变更的闭环
5.3.1 先选小任务，不要选大任务
5.3.2 一条够用的执行泳道
5.3.3 一个典型最小变更案例
5.3.4 第一次要盯的，不是代码量，而是链路完整性
5.3.5 准备提交时要补一层人工判断
5.4 从个人闭环到团队资产：复用、成本与模型选择
5.4.1 把个人习惯沉淀成项目资产
5.4.2 理解Codex的成本消耗结构
5.4.3 模型选择先看风险，再看复杂度
本章小结
第6章 AGENTS.md：给Agent的项目说明书
6.1 项目地图、关键入口与禁区
6.2 根目录与子目录分层
6.3 团队规则与个人偏好
6.4 角色分工、交接协议与值班边界
6.5 三类模板：新项目 / 遗留项目 / 团队项目
6.5.1 新项目最小骨架
6.5.2 遗留项目最小骨架
6.5.3 团队项目最小骨架
6.5.4 模板怎么选，怎么升级
本章小结
第7章 Rules、Hooks 与 Approvals：先约束，再放权
7.1 为什么实现智能之前要先控制
7.1.1 风险不止幻觉
7.1.2 把控制理解成分层栈
7.1.3 先保守，再逐步放权
7.2 自动格式化、测试、审计、阻断
7.2.1 四类控制动作的职责
7.2.2 触发时机与最小链路
7.2.3 别把护栏变成形式检查
7.3 审批点怎么设计
7.3.1 审批点应该放在风险跃迁处
7.3.2 四级审批模型通常就够用了
7.3.3 审批链要能接住责任
7.4 高风险仓库的护栏模板
7.4.1 高风险仓库至少要同时控制4件事
7.4.2 护栏模板要同时落地在文档、脚本和流程中
7.4.3 外围护栏与按任务放权
本章小结
第8章 Skill、Subagent 与 MCP：用Harness把能力和上下文装进系统
8.1 从剧本到Harness：什么时候值得能力化
8.1.1 Harness设计的是可运行边界
8.1.2 一个Skill至少要有稳定结构
8.1.3 不要把所有经验都包装成Skill
8.2 Subagent 如何拆分复杂任务
8.2.1 适合拆分的，不是“大任务”，而是“可分段任务”
8.2.2 子任务必须可合并
8.2.3 主线程负责整合和判断
8.2.4 拆分不是终点，回收才是
8.3 MCP：先问是否值得接，再问怎么接
8.3.1 接入方式存在不同的版本
8.3.2 只读型接入优先，高风险接入后置
8.3.3 MCP值不值得接入，要看能否减少任务摩擦
8.4 Skill、Subagent和MCP相互协同，而不是堆叠复杂度
8.4.1 装配原则：能少一层就少一层
8.4.2 能力系统需要反馈、评测和交接
8.4.3 编排层不要重写执行器
本章小结
第9章 场景一：接手陌生代码库
9.1 Subagent：从串行阅读到全局俯瞰
9.1.1 实战：并行勘察 emotional_chat 项目
9.1.2 并发度的实操边界
9.1.3 用Git worktree把并行勘察延伸至并行修改
9.2 AGENTS.md：给 AI 定规矩
9.2.1 AGENTS.md 的核心结构
9.2.2 从个人偏好到团队规范的三层规则
9.2.3 已知陷阱：把犯过的错误写进规则
9.2.4 搜索工具链：fd / rg / sg 的分工
9.2.5 Rules：让约束按场景生效
9.3 先理解，再修改
9.3.1 代码理解的四层结构
9.3.2 从全局视图进入局部深挖
9.3.3 修改前必须做影响分析
9.4 产出审查友好的最小变更
9.4.1 一个最小变更示例
9.4.2 提交说明也要服务于审查
9.5 遗留项目的Harness工程
9.5.1 先改善上下文，再修改代码
9.5.2 从认识到改造：四阶段执行框架
9.5.3 用Strangler Fig降低迁移风险
本章小结
第10章 场景二：修复bug、补测试、做回归
10.1 复现问题：从错误日志到结构化的bug报告
10.1.1 不要直接粘贴原始日志，而应将其整理为结构化的bug报告
10.1.2 引导Codex沿调用栈追溯数据流
10.1.3 复现测试是后续修复的基准
10.2 约束修改范围：防止“顺手”重构
10.2.1 最小修复应该是原子的
10.2.2 给Codex的修复指令要同时包含边界约束和验证需求
10.3 AI 生成测试：从表面达标到真正可靠
10.3.1 好的测试要能说明行为
10.3.2 用Fake代替过度的Mock
10.3.3 代码覆盖率不是黄金标准
10.3.4 基于属性的测试：从枚举样例到验证不变量
10.3.5 测试影响分析：先执行高相关测试
10.4 验证闭环：复现→修复→回归
10.4.1 把闭环转化为可复用指令
10.4.2 利用 git bisect 与 Codex 反查问题引入点
10.4.3 回归测试应分层执行
10.4.4 契约测试是API的防断裂保险
本章小结
第11章 场景三：跨前后端功能开发
11.1 需求的结构化拆解：从模糊到精确
11.2 API契约的演进：从手动同步到自动生成
11.2.1 先发现契约漂移，再判定事实来源
11.2.2 利用自动生成消除重复维护
11.2.3 规范优先、代码优先和运行时校验需要明确边界
11.3 数据库迁移：风险最高的一步
11.3.1 迁移风险不只藏在Migration文件中
11.3.2 把一次迁移拆解成向前兼容的多阶段发布计划
11.3.3 迁移审查清单需要纳入团队默认规则
11.4 渐进式交付：从写完就发布到灰度发布
11.4.1 Feature Flag 控制的是入口，而不是发布纪律
11.4.2 设计系统也需要进入上下文
11.4.3 前后端协调发布要建立向前兼容窗口
11.5 一次通过率：信息对齐是核心
本章小结
第12章 场景四：PR、Review与CI/CD自动化
12.1 非交互模式：无人值守的前提条件
12.2 CI 自修复：从构建失败到自动提交PR
12.2.1 自修复闭环的核心并非“自动合并”
12.2.2 成本与失败率需要协同控制
12.3 AI辅助代码审查
12.3.1 不同任务场景下的收益差异显著
12.3.2 审查应仅输出审查意见，不直接修改代码
12.4 超越代码审查：安全扫描与 GitOps的演进
12.4.1 安全扫描宜采用“工具初筛 + AI 精排”模式
12.4.2 GitOps自动化必须保留关键审批点
12.5 自动化的边界：风险分级与信任建立
12.5.1 用四级自动化风险分级框架决定自动化权限
12.5.2 信任需要通过渐进式落地建立
本章小结
第13章 从个人开发助手到团队级研发流程
13.1 什么时候值得推行团队化
13.1.1 评估团队化的三大维度：任务重复度、规则稳定性与协作密度
13.1.2 当“隐性知识”不再可靠
13.1.3 优先试点，而非盲目全面升级
13.1.4 循序渐进：从构建一条共享主线开始
13.2 共享规则、权限与能力包
13.2.1 共享资产至少包含5类
13.2.2 权限与能力包应协同设计
13.2.3 统一默认路径，保留个人偏好
13.2.4 明确资产责任人，划定成本边界
13.2.5 知识库、操作手册及预案：能力包的深层支撑
13.3 Worktrees、云端任务与异步协作
13.3.1 优先明确团队级任务主线
13.3.2 Worktrees负责并行隔离，而非替代团队决策
13.3.3 云端任务适配长周期运行，值班动作要优先扩大观测面
13.3.4 异步协作的前提：确保交接信息可读
13.4 小团队试点落地的合理顺序
13.4.1 一套切实可行的试点推进顺序
13.4.2 夯实三大前提，再行自动化升级
13.4.3 为试点设定明确的退出条件
13.4.4 以轻量指标衡量扩展价值
本章小结
第14章 Codex的边界、风险与工程方法论
14.1 幻觉、越界与错误归因
14.1.1 先把失败类型分清
14.1.2 三类问题要用三种治理路径
14.1.3 最危险的是错误类型混在一起
14.2 版权、隐私与安全边界
14.2.1 先分清楚三类边界的关注对象
14.2.2 把边界落实到默认动作
14.2.3 一个够用的团队边界模板
14.3 让Agent 做高噪声工作，让人做关键判断
14.3.1 高噪声工作适合下放，关键判断必须留给人
14.3.2 任务阶段不同，分工也不同
14.3.3 两种坏分工：判断被偷走，噪声留给人
14.4 从一次成功到长期可复用的工作流
14.4.1 一次成功中，真正值得提炼的是什么
14.4.2 复盘要记录系统怎么运行
14.4.3 从个人有效到团队可复用，中间隔着验证
14.5 配套仓库、模板与在线更新机制
14.5.1 正文和仓库应该怎么分工
14.5.2 配套仓库最好按“拿来就用”组织
14.5.3 在线更新不是追新，而是持续校正
本章小结
买过这本书的人还买过
读了这本书的人还在读
同类图书排行榜
购物车
个人中心
