写投资、写 AI，也写那些值得长期复利的判断。

我现在的「AI 工作台」：codex + Cindy + openclaw + kilo 最近被朋友反复问同一个问题：你这四个 AI 工具到底是怎么分工的？codex、Cindy、openclaw、kilo，光听名字确实都像"AI 助手"，凭什么不全用同一个？我自己也花了不少时间才把这套组合理顺。这篇文章只讲一件小事：在我手里，这四个工具分别占住了不同的工作位，缺谁我都会别扭。 我写代码的"主驾"是 codex。这里的"主驾"很具体：跨多文件、需要持续迭代、上下文一旦断了就接不回去的那一类项目。我把 codex 一直挂着，它不像一个"一次性问答工具"，更像一个能跟项目同呼吸的搭档——它看过的文件、改过的 diff、跑过的命令，会变成下一轮决策的依据。规矩只有三条：把 codex 当"项目主驾"而不是"问答工具"，给它持续的事实而不是一次性的提示；用里程碑切会话，长会话里它会慢慢漂移，里程碑一过就 reset，让它从干净的事实开始；看 diff 而不是看回答，它给的"通过"只是参考，最终那一下"合不合"必须人来定。 Cindy 站的是另一个位。她不只是"另一个 AI"，更像是四个工具之间的调度位。一半的时间我在做办公——写周报、整会议纪要、做汇报材料、起草对外的邮件——这摊事她是我的主力。但更让我离不开的，是她无缝衔接 Pi、codex、Claude的能力。我经常是这样跑工作流的：先用 Cindy 把需求讲清楚、列好要点；遇到需要长链路推理的，把上下文接力给 Pi；进入真正的工程实施阶段，再接力给 codex；想换一个视角听反馈或做对照，再回到 Cindy 或转 Claude 跑一遍。整条链路的纪律是：办公是基本盘，周报、会议纪要、对外邮件这一摊她是主力；调度是放大器，她和 Pi / codex / Claude 接力，让上下文在工具之间流动，我不用复制粘贴、不用重新解释背景；接力链路过长是陷阱，两到三跳最舒服，再多，信息的损耗就会显出来，必须切回 Cindy 重整。 再往下是 openclaw。它在我这里干的是"不入主线"的杂活。什么叫杂活？一次性脚本、临时数据清洗、批量改个文件名、跑个不痛不痒的小爬虫、把一段音频转成文字、给一张图换个尺寸、临时翻译一段不要求精度的文字——这些事不会上 GitHub、不会进生产、也不会被任何会议引用，但不做又会卡住主线进度。openclaw 就是这种"轻骑兵"，打开就能用、用完就走。规矩是：任务的边界是"不入主线"，都是它的活；价值在"快"和"不打断心流"，不在"严谨"和"可追溯"，别把它的输出直接当交付物；用完就走，它不占心智位，也不抢主线位。 kilo 的角色最简单：在 VSCode 里用的那个。很多写代码的时间是碎片化的——我在 IDE 里写到一个函数、卡住、想问一下；改到一半想确认某个 API 的用法；review 一段刚写的逻辑想找人挑刺。这时候我不想切窗口、不想开新 tab、不想跳出当前文件，kilo 就在侧栏里直接接住。规矩也很简单：位置在 VSCode 侧栏，随手就能用，不切窗口；任务是碎片化的"边写边问"，卡住的函数、API 用法、刚写完的逻辑想挑刺，kilo 就在手边；不要在 kilo 里跑长链路任务，它的定位是"边写边问"，不是"项目级搭档"，那个位是 codex 的。

纳瓦尔宝典：AI 时代，借 AI 之力撬动个人能力与财富的复利 原文：The Almanack of Naval Ravikant: A Guide to Wealth and Happiness 作者：Naval Ravikant（硅谷天使投资人，AngelList 创始人） 编撰：Eric Jorgenson 来源：Magrathea Publishing，发布于 2020 年 09 月 中文版：中信出版社，2022 年 05 月，赵灿 译 最近在重读《纳瓦尔宝典》，一句话反复击中我——「财富 ≠ 劳动」。但这次重读的体感，和前几次很不一样：以前我把这句话当成一种「价值观提醒」，告诉自己别太累；现在 AI 全面进入工作流之后，我才发现纳瓦尔讲的其实是一种「杠杆公式」，而 AI，是 21 世纪最便宜、最高倍的那一种杠杆。这篇文章，我想把纳瓦尔关于「财富 / 杠杆 / 判断力」的核心观点重新梳理一遍，并把它们放进 AI 时代这个新变量里，回答一个更现实的问题——作为没有任何特殊资源、也没有团队背书的普通人，我们怎么借 AI 之力，以最小付出去撬动个人能力与财富的双重复利？ 一、AI 改变的，不是「杠杆本身」，而是「杠杆的门槛」。 纳瓦尔反复讲一句话：「我们这代人最被高估的东西，就是劳动本身。」劳动只能线性放大你的时间，而 财富是指数级增长的——他给出了一个非常冷静的区分：劳动是用时间换钱，金钱只是财富的流通形式，真正的 财富，是你睡觉时依然在为你工作的东西。在他那本《宝典》里，他把放大劳动的工具分成「劳动力 / 资本 / 代码 / 媒体」四类杠杆，并指出：前两类需要别人「许可」，后两类才是普通人的金矿。但放到 2024 年之后，这件事又变了一次：AI 出现之后，「代码」和「媒体」这两条无许可杠杆的门槛，被一次性打到了地板。以前你想写一个工具，需要学一门语言、搭环境、踩无数的坑；现在你只需要把需求说清楚，AI 就能给你一个能跑的版本。以前你想持续生产内容，需要文笔、时间、选题、拍摄；现在 AI 可以帮你写初稿、配图、剪辑、校对。门槛下降，杠杆率反而在上升——这才是 AI 真正改变的事。 二、AI 时代，普通人能用的「五种新杠杆」。 纳瓦尔讲的是四类「杠杆」，结合我自己的 AI 使用经验，我把它们重新整理为「五种更接地气的杠杆」，并按「普通人友好度」排序： AI 杠杆的能力外骨骼——你不是变强了，你是装上了外骨骼。写作、设计、分析、翻译、代码、PPT，这些过去需要多年训练的能力，现在 AI 都能给你一个 70 分的起点。你不是不能做，只是过去做一次的成本太高。 AI 杠杆的内容生产——一个人 = 一家内容公司。选题、写作、配图、排版、分发，过去需要一个小团队；现在一个人 + AI 工作流就能稳定产出。这是「媒体杠杆」的 AI 加持版。 AI 杠杆的产品制造——一个人 = 一家小产品公司。无代码 + AI 辅助开发 + AI 辅助运营，让「做一个自己的小产品」从过去的半年变成现在的两周。这是「代码杠杆」的 AI 平民版。 AI 杠杆的信息差消除——以前你做判断，靠经验和信息差；现在 AI 可以几秒钟内帮你拉齐行业资料、对比方案、列出反例。判断力没变，但判断的依据变厚了。 AI 杠杆的人际连接——AI 帮你整理客户、读邮件、写回复、做会议纪要；你不再被事务性工作淹没，可以把时间花在「真正需要人的地方」——关系、信任、长期价值。 纳瓦尔反复强调：杠杆只是放大器，方向错了，杠杆越大，摔得越狠。在 AI 时代，这句话变成了一个更具体的提醒：如果你用 AI 加速了一件错误的事，你只会更快地失败。 ...

20260904｜我如何把 Pi Agent 接进 Office/WPS 办公流程：从安装到 Excel 长任务 我最初接触 Pi Agent 时，也只是把它当成一个写代码的终端工具。真正让我觉得它适合办公，是我把一项复杂任务拆开之后发现：办公里最耗时间的部分，往往不是写一段话，而是把邮件、会议记录、网页、表格和历史文件里的信息拼起来，再按一套不够明确的规则反复处理，最后还要证明结果没有改错。 关键词：#Office #WPS #Pi 对经常使用 Office 或 WPS 的人，我更愿意把 Pi 理解成一个坐在旁边的办公助理：它不替我换掉 Word、Excel、PowerPoint 或 WPS，而是帮我在多个文件之间找信息、整理内容、生成草稿、执行低风险的重复动作。它可以在本地的“办公工作区”——也就是我专门放这项工作的文件夹——里读取资料、调用工具、保存一次连续的工作记录，并把中间结果留下来。但它不是“按一下就全自动”的魔法，也不是替我做业务判断的数字员工。 本文先把安装对象和桌面适配讲清楚，再用 Excel 月报这个长任务说明我如何让它参与办公，以及我为什么坚持把验证和最终提交留给自己。先把名字理顺：大家口中的“pi-agent”，对普通使用者来说通常指的是会安装出 pi 命令的 @earendil-works/pi-coding-agent；@earendil-works/pi-agent-core 是底层运行时库，不是新手第一步要装的客户端。下面的命令和版本判断以我在 2026 年 9 月 4 日查到的官方快速开始文档、官方仓库和相关 package 资料为准。 下面看到的黑色窗口命令，主要只在安装和整理文件时使用；装好以后，我仍然可以继续用熟悉的 Excel、Word、PPT 或 WPS 图形界面办公。对不熟悉命令行的朋友，我建议把它理解成“给办公助理下达准备工作指令”，先照着复制执行即可。 先准备运行环境：当前官方仓库的 package.json声明 Node.js >=22.19.0。Node.js 是 Pi 运行所依赖的基础环境，我会先用 node --version 检查版本；低于这个版本就先升级 Node.js。旧文章里如果还写着 @mariozechner/pi-coding-agent，以当前官方文档使用的 @earendil-works/pi-coding-agent 为准。然后安装并验证： npm install -g --ignore-scripts @earendil-works/pi-coding-agent pi --version macOS 或 Linux 也可以使用官方安装脚本 curl -fsSL https://pi.dev/install.sh | sh；Windows 则建议先安装 Git for Windows，因为 Pi 默认通过 Git Bash 执行 Bash 命令，官方也支持在设置里指定 shellPath。安装成功后，进入我准备给它工作的目录再启动： ...

Go 语言架构｜Google ADK Go 深入拆解：把 Agent 写进 Go 的工程流水线 原文：Agent Development Kit (ADK) for Go 作者：Google ADK Go 团队（Google 官方开源项目维护者） 来源：GitHub，发布于 2025 年 11 月 06 日 我最近重新看了一遍 Google 的 ADK Go。它吸引我的地方，并不是“Go 也有一个 AI 框架”，而是它试图回答一个更实际的问题：一个会调用模型、工具和其他 Agent 的系统，能不能像普通 Go 服务一样被编译、被测试、被部署和被审查？ 这篇文章不打算把官方 API 逐个翻译一遍。我会沿着自己的理解，把 Agent、工具、工作流、协议、状态和上下文串起来，也会特别标出 v1 与 v2 的边界。文中的蓝色表示工具或事实，绿色表示我的实践判断，红色表示容易踩的坑，黄色底色表示可以直接拿去用的做法。 先看 ADK Go 为什么值得单独关注。 我认为，ADK Go 的重点不是证明“Go 比 Python 快”，而是让 Agent 代码进入成熟的软件工程流程。Go 项目已有的编译器、静态检查、单元测试、依赖管理、CI 和容器化能力，都可以继续使用。 ...

20260903 OpenCode 和 KiloCode 的主要区别是什么？为什么我会选择 KiloCode？ 最近 OpenCode 和 KiloCode 经常被放在一起讨论：一个让我在终端里专注完成任务，一个把多个 Agent、隔离工作区和代码审查组织进 IDE。很多朋友真正想问的其实不是“谁更强”，而是“我现在的工作方式，应该把哪一个放在手边”。这篇文章记录我最近一次切换工具的原因，也把我认为最影响选择的差异讲清楚。蓝色高亮表示工具事实，绿色高亮表示我的判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接尝试的做法。文中的产品信息按 2026 年 9 月 3 日查阅到的官方文档整理，后续可能随版本变化。 先说我的结论：如果你主要在终端里工作，喜欢自己控制会话、目录和模型，OpenCode 依然是一把很顺手的工具；如果你经常同时推进多个任务，希望在 VS Code 或 JetBrains 里集中看状态、diff 和工作区，KiloCode 更贴合我的习惯。更准确地说，Kilo CLI 是 OpenCode 的 fork；Kilo 的 IDE 插件和 Agent Manager 则是 Kilo 另行组织的产品层。所以它们不是两个完全无关的竞品，也不是同一个产品换了两个皮肤。 我为什么又换了一次？上一篇文章里，我写过自己怎样把 OpenCode 接进日常开发，那些经验现在仍然有效：终端里可以跑命令，配合 LSP（语言服务协议）理解代码，也可以通过 MCP（模型上下文协议）接入外部工具，项目规则则写进 AGENTS.md。后来我的任务从“一个人在终端里重构 Go 服务”，变成了同时推进重构、补测试、写文档、审 PR 和修 bug，还要在 VS Code 与 JetBrains 之间来回切换。OpenCode 的多 session 能力并不弱，只是我需要自己安排目录、创建 git worktree（并行分支工作区），再盯住每个会话的进度。KiloCode 的 Agent Manager 把这部分协调工作做成了看板：每个 Agent 可以在独立 worktree 里运行，我只需要负责拆任务和合并结果。 ...

8 月 27 日，Cursor 在 changelog 中上线了一个看似不起眼的功能更新：Cloud Agents 不再需要连接 GitHub 或其他第三方 SCM 提供商，用户可以直接从零开始，prompt 之后自动创建 Cursor Origin 仓库。 这个功能在嘈杂的 AI 工具发布潮中容易被忽略。但如果我们把它放在 Cursor"self-driving codebases"的长期愿景里看，它标志着一次重要的战略转向。 为什么这个更新重要 传统编程工具对 GitHub 有强依赖。即使是 AI 辅助编程工具，也假设你有一个既存的代码仓库。从零开始写代码？先建 repo、先初始化项目结构——这些"准备工作"在传统工作流里是不可跳过的。 Cursor 的"Start from scratch"打破了这个假设。用户只需要描述想做什么，Cursor 自动创建项目、写入代码、运行构建，最终可以一键发布到 Vercel 获取公网 URL。这不是编程辅助，这是编程替代的雏形。 更深层的变化在于产品定位的迁移：从"IDE 插件"到"应用平台"。Cursor 不再只是帮你写代码的工具，而是接管从想法到可访问应用的完整链路。用户甚至不需要知道什么是 Git、什么是 npm start。 技术实现：Origin 托管的战略价值 Cursor 在背后创建了"Origin repo"——这是他们自建的代码托管服务，8 月 17 日的 changelog 已经预告了 Origin Code Hosting 的推出。 自建托管服务的原因很实际： 消除第三方依赖：GitHub 的 API 限制、认证流程、仓库可见性规则都是约束。自有托管可以让 Cursor 完全控制 Cloud Agent 的代码存储和检索逻辑。 与 AI 工作流的深度集成：传统的 Git 仓库是为人设计的——提交历史、分支模型、PR 流程。AI 生成代码的节奏完全不同，传统的版本控制模型并不天然适配"Agent 大量生成、人类审批"的场景。Origin 可能针对 AI 工作流做了定制。 数据飞轮：代码托管与 AI 能力形成闭环。Cursor 可以分析自身的代码生成质量、在不同项目类型上的表现，这些数据可以用来改进模型路由和 agent 行为。 行业影响：打破 GitHub 护城河 GitHub 长期以来是开发者生态的"守门人"。Copilot、Claude Code 等工具都以 GitHub 为基础构建工作流。Cursor 选择自建托管并支持无 repo 启动，意味着GitHub 不再是 AI 编程工具的必要条件。 ...

OpenCode，别急着上手，分享我的自用经验 最近一段时间 OpenCode 的话题度很高，公众号和推上每隔几天就有人晒"一天配置、终身起飞"。我也凑过几次热闹，但说实话，真正把它当成日常开发工具并接入 AI 用，是在吃了几次亏、调过几次规则之后才稳定下来的。这一篇不是官方文档的搬运，也不是"hello world 教程"，我会先讲我为什么把 OpenCode 作为日常开发工具并接入 AI 用，列 8 条最容易踩的注意事项——尤其是"装上第一天别急着写规则"。如果你正在评估 OpenCode、或者已经装上却不知道从哪一步开始，这篇可能比"快速上手"那一份更值得花十分钟读完。蓝色高亮表示工具或事实，绿色高亮表示我的使用判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接抄走的最小可用集。、 先把"为什么用"想清楚：换模型不被绑架、过程可观察、本地运行——这三条都满足了，再谈下一步。 从最小可用集开始：一份简短 AGENTS.md + 一个稳定 Provider + 一个默认 build 角色 + 启用的 LSP。够用就好。 复杂任务先 plan 再 build：跨文件的改动，先看 diff 再下手，能避免一整轮返工。 规则要可验证、规则要文件化：机器能判的才叫规则，读不懂的只是愿望。 审查用只读 agent：把"看"和"改"分开，是让 AI 报告客观的前提。 接入 MCP 时按"只读 → 受限可写 → 状态变更"分步放权：每一步都先想清楚"最危险的事是什么"。 不要让关键检查静默失败：可见、可追溯、有人负责，三条缺一不可。 把 AI 当草稿作者，把自己当责任编辑：最终交付的责任，不能下放给工具。 一、把 OpenCode 放进工作流之前，我给自己提过三个问题：它能不能让我换模型不被绑架？它能不能把每一步操作摊在我眼前？它能不能在我自己的机器上跑，而不是把代码交给一个远端托管？ OpenCode 在这三个问题上都给出了让我愿意留下来的答案，这也是我后来把它接入 AI 用作日常开发工具的真正原因。我把这三个答案按顺序写下来，因为它们不只是在"功能上"成立，更是OpenCode 与同类工具最明显的差异点： 开源、可审计、不绑定单一供应商：OpenCode 的客户端代码是公开的，关键行为可以在源码里核对；Provider（也就是模型供应商）走的是开放协议，我可以在同一个配置里同时挂上 OpenAI、Anthropic、本地 Ollama、自建代理，换模型不需要重写工作流，更不需要换一份订阅。对我来说这意味着两件事：第一，今天贵/限流的模型，明天可以被另一个模型接住；第二，今天数据合规的顾虑，明天可以通过本地模型或者自建网关绕过。这条不是装饰，它直接决定了我愿不愿意把生产代码交给它。 把"工具调用 + 文件编辑 + 命令执行"收进一个 TUI：比起网页聊天窗口，OpenCode 的好处是上下文连续。一次会话里，它可以直接读写我的文件、跑我的命令、调用我的 LSP，并把每一步的结果作为下一步输入。传统聊天窗口要靠我在不同窗口之间复制粘贴，OpenCode 把这些步骤变成了同一个会话里的多轮工具调用。对我而言这比"模型写得多聪明"更重要：我能在同一个界面里看见它读了什么、改了什么、跑过哪些命令、回滚时还能回到哪一步。信任不是靠宣传词建立的，是靠"可观察"建立的。 配置即文档，规则可以在 review 里被讨论：OpenCode 的绝大部分约定都放在纯文本文件里：项目根的 AGENTS.md 写规则，commands/*.md 写命令模板，agents/*.md 写角色，skills/*.md 写沉淀下来的做事方法。最常见的错误是把 AGENTS.md 当成无所不包的"价值观大全"，其实它的价值恰恰相反——把"我想要的工作方式"显式写下来，让工具按文件读，而不是每次新会话都让我重新解释一遍。规则在哪一步生效、谁负责什么，可以被同事直接读到，也可以在 review 里被讨论。这就是我把 OpenCode 当成"开发工具并接入 AI 用"的核心原因——AI 第一次成为工作流的一部分，而不是一个聊天侧栏。 二、装上 OpenCode 之后，先别急着让它"做项目"。我会先定一个最小可用集，把"模型 + 规则 + 角色 + 编辑器反馈"四件事按顺序配齐，再开始干正事。顺序不能乱，因为规则没写好之前，模型越强越容易跑偏。下面这 8 条技巧，前 4 条是"装好就能用"的最小集，后 4 条是"日常真正省时间"的核心姿势，全部按顺序展开，每一条都尽量具体到"打开哪个文件、敲哪条命令、看哪个输出"。我会刻意把"我踩过的坑"嵌在技巧后面写，而不是单独列一节，这样读起来不会割裂。 ...

AI 写的代码，为什么总像“差不多对”？我用 opencode 把 commit 前审查做成三道门 我用opencode做代码审查，注重agents.md的质量，聚焦多轮核心BUG输出质量，减少MR被驳回的风险 审查阶段不要使用可写 agent。 可写 agent 看到问题后很容易顺手修复，修复后的代码又变成新的审查对象。我要的是报告，不是未经确认的工作树变化。 AGENTS.md 不是越长越好。 我见过把抽象价值观、编码风格和所有历史事故都塞进去的规则文件，最后 AI 什么都读到了一点，却没有一条真正执行到位。规则应当短、具体、可验证。 不要只统计 AI 提了多少条意见。 我更看重高价值意见的比例、误报率、漏报案例和处理耗时。意见越多不等于审查越好。 我最近在 Go 项目里遇到过一个很典型的例子：我让 AI 把一个用 sync.Mutex 保护的缓存改成 sync.RWMutex，因为读请求远多于写请求。代码能编译，go test -race 也通过了，我正准备提交时又看了一遍 diff，才发现 AI 在 RLock() 之后没有为所有提前返回的分支补上 RUnlock()。原代码用 defer Unlock() 做了一次兜底，锁的种类变了，兜底结构却没有一起变。 这个问题不是函数体“完全写错”，而是局部正确、整体破坏。测试没有触发那个错误分支，竞态检测自然也抓不到。类似的情况我见过很多：错误被 _ 接住、context 半路丢失、goroutine 没有退出条件、异常路径没有补齐、依赖被悄悄换成团队没人维护的库。AI 生成代码的速度越快，diff 的影响半径就越容易被低估。 我现在把 commit 前的审查拆成三道门：机器门负责确定性检查，AI 自审负责挑出候选风险，人工 review 负责业务判断和最终签字。这篇文章记录我在 Go 项目里实践这套流程的方式，也会说明 opencode 适合放在哪一层、哪些事情仍然不能交给它。 蓝色 表示工具或事实，绿色 表示我的实践判断，红色 表示容易踩的坑，黄色 表示可以直接改写到自己项目里的模板。 一、先把 commit 当成一次小型发布 以前我把 git commit 当作保存进度，后来几次线上问题让我改了看法：commit 是把一组行为变化交给团队和环境的发布动作。即使还没有上线，它也已经影响了后续 review、合并、回滚和事故追踪。 ...

AI 生成代码该怎么审：一套可以直接使用的实操框架 我的核心要求：减少 BUG，减轻 Review 压力，避免生产环境出现不可逆的风险。不要怕对同一个任务开多个agent，重要的是让不同关注点能充分执行，人工做最后的审核兜底； 一、AI 写得越快，审查越不能只看“像不像对的” AI 一分钟可以生成几百行代码，几小时就能跑完一轮 PR 流程。真正决定质量的，已经不只是 AI 写得快不快，而是我们能不能在代码生成之后，用合适的方法把它审干净。我自己每天让 AI 生成大约一半的代码改动，但最后原样合进主干的，大概只有三成。剩下的代码往往不是“完全写错”，而是“看起来很像对”：错误被 _ 接住，权限校验在调用链里悄悄漏掉，并发场景只覆盖了 happy path，或者引入了一套团队没人熟悉的依赖。这些问题可能过得了 lint、单元测试和评审，却会在生产环境里变成真正的事故。 所以，我现在不把 AI 当成“替我批准代码的人”，而是把它放在风险筛查器的位置：先帮我快速找出值得追问的地方，再由作者、人工 Reviewer 和领域负责人作最终判断。这个定位也和公开实践比较一致：OWASP 把人工代码审查定义为对自动化安全测试的补充，重点放在业务逻辑、复杂安全实现和具体上下文上；Google 的评审指南则强调，测试本身也需要人来判断是否真的有效。可参考 OWASP Secure Code Review Cheat Sheet 和 Google 的代码评审实践。 二、先把审查输入准备好，AI 才不会对着空气猜 我以前最容易犯的错，是把一段代码直接丢给 AI，然后补一句“帮我仔细审查”。现在我会先准备一张很短的“审查输入卡”，至少包含下面五项： 目标：这次改动要解决什么问题？不解决什么问题？ 不变量：哪些已有行为、权限边界、接口兼容性和数据约束绝对不能被破坏？ 范围：本次 PR 改了哪些文件、调用链和配置？哪些内容只是必要上下文？ 验证：新增或修改了哪些测试？正常路径、异常路径和回滚路径分别是什么？ 风险：是否涉及登录、权限、支付、个人信息、文件上传、数据库迁移、加密或外部依赖？ 日常 PR 我会让 AI 以 diff 为主，只补充相关接口、数据结构、配置和测试。OWASP 也把 diff-based review 作为 Pull Request 和日常开发的适用方式；新系统、重大版本、遗留系统接管或事故复盘，才更适合做全量的 baseline review。另一个有效做法是控制 PR 的大小：Google 建议一个变更尽量只做一件自洽的事，相关测试跟着代码一起提交，大型重构与功能修改分开。这样做的收益很直接：AI 看得少而准，人也更容易发现真正的行为变化。 ...

减少 AI 返工，我现在一般这么做 原文：Review AI-generated code 与 AI 代码审查实践的综合解读 作者：我（结合个人 AI 编程实践整理） 来源：GitHub、Uber、Cloudflare、Trellis 等公开资料，整理于 2026 年 08 月 26 日 AI 写代码越来越快，但返工并没有因此自动消失。我现在更关心的，不是 AI 一次写了多少，而是错误能不能更早暴露、修改能不能更小、人工判断能不能用在真正重要的地方。 这篇文章记录的，就是我目前用来减少 AI 代码返工的一条实践路径。 一、我以前把 AI 当成“写得更快的人”，后来发现它更像“放大器” 刚开始用 AI 写代码时，我最在意的是它能不能一次生成几百行、能不能把一个需求快速改完。后来真正经历了几轮线上问题、PR 返工和反复讨论，我才意识到：AI 放大的不只是产出速度，也会放大需求里的空白、上下文里的误导和开发者自己的错误判断。代码生成得越快，如果没有同步增加验证能力，Review 只是被动接收更多半成品。 我最近看了一些开发者分享和团队实践，大家的结论其实很接近：不要把“AI 写了多少代码”当成成功指标，而要看它是否减少了无效沟通，是否能在进入人工 Review 前被自动检查，是否让 reviewer 更快理解真正的风险。GitHub 的官方建议也很直接：先检查功能、上下文和意图，再看代码质量、依赖和安全；最终合并责任仍在开发者身上。我现在给自己的目标因此换了一个说法：不是保证 AI 一次写对，而是让错误尽可能早暴露，让每一轮修改尽可能小，让机器能判断的事情不要消耗人工判断，让必须由人判断的事情明确标出来。 二、写之前先做上下文盘点：不要让 AI “自己理解整个仓库” 我遇到过最浪费时间的一类任务，是直接对 Agent 说“先理解一下这个仓库，再实现功能”。小项目这样做问题不大，仓库一大，Agent 往往会先花很多时间猜目录结构，读到相似但已经废弃的实现，最后在错误的上下文上给出一份看起来很合理的方案。社区里有开发者把自己的流程总结成：先画仓库地图，再找相关文件，检查上下文是否足够，最后检查回答是否确实基于这些文件。我照着这个思路调整后，最大的变化不是回答更长，而是少了“改错文件”和“参考旧逻辑”的返工。 我现在会把任务拆成四步： 先定位：让 AI 只列出与任务直接相关的目录、入口、调用方、测试和配置，不要马上改代码。 再确认：让它说明每个文件为什么相关，哪些文件只是相似样例，哪些内容可能已经过期。 再补上下文：补充接口契约、数据库结构、历史 PR、业务规则和失败案例；如果这些信息没有提供，就明确标成未知。 最后锁范围：规定允许修改的文件和不允许顺手做的重构，要求它在动手前复述范围。 我会先使用这样的提示： 先不要写代码。请完成以下任务： 1. 列出本任务涉及的入口、调用链、数据结构、测试和配置； 2. 区分“已从仓库确认的事实”和“你的推测”； 3. 指出还缺少哪些上下文，以及缺失它们会影响什么判断； 4. 给出最小改动计划，列出准备修改和明确不修改的文件； 5. 等我确认计划后再实现。 这里有一个容易被忽略的细节：我不会把所有文档一股脑塞给 AI。上下文太多同样会稀释重点，我更倾向于使用“渐进披露”：先给仓库地图和任务相关文件，遇到具体问题再补充协议、ADR、历史 PR 或业务文档。AI 必须回答“我实际参考了哪些文件”，而不是笼统地说“我已经理解整个项目”。上下文的关键不是多，而是相关、最新、可核对。 如果它引用了过期文档，我会先停下来校正上下文，而不是继续修补错误答案。 ...