编码智能体

视角 · 最容易踩的坑在最后一条：换成本地模型不等于代码不出机器。对代码有保密要求的团队，我建议把 COPILOT_OFFLINE=true 写进统一配置，而不是靠每个人记得切模型。

视角 · 默认模型一换，同样的脚本成本和输出风格都会变。CI 里跑 codex exec 的团队，我建议把模型显式写死，等在非关键任务上比完 Sol 的效果和账单再切。

视角 · 让编码智能体放手跑，最大的顾虑一直是它在本机能碰到什么。我会先把团队的默认策略定成「只能写当前仓库、禁止读 Git 凭据、联网走白名单」，本地 MCP 服务器也一并纳入；这比事后审查每一条命令省心得多。用其他编码智能体的团队，也该照这个标准检查自己的隔离做法。

视角 · 智能体每步都在提交，密钥混进历史的概率只会更高，push 时就拦下比事后轮换便宜得多。我会先在已买 GHSP 的仓库开推送拦截试点，同时给 AI Credits 设预算上限，因为不拦截也会计费；GitHub 在说明里还特意写了「智能体不应在未授权时开启计费功能」，这条值得原样写进团队的智能体规则。

视角 · 「技能」正在变成云厂商争夺编码智能体入口的新方式：谁的部署经验被装进智能体，谁的平台就更容易被选中。它产出的是代码而不是黑盒操作，这点我认同；但跑压测会真实开端点、产生费用，先在单独的账号里设好预算上限再让智能体动手。

视角 · 有了 API，AI 评审可以挂进自己的发布流程，比如只在改动涉及支付或权限时调高力度。默认力度变了，评审耗时和额度消耗可能随之变化，这周值得看一眼账单和 PR 等待时间。AI 写初稿后评审怎么分工，我在博客《当 AI 承担大部分初稿时的代码评审实践》里写过。