xingkaixin.me/tags/工程实践

Tag archive

#工程实践

23 篇 · 按时间倒序

Agent 为什么越学越不稳定？它需要一套 Git 状态控制

给 Agent 加上 Auto-Memory 和自适应 Skill 之后，为什么它的行为越来越不可控？当记忆、技能、脚本与定时任务产生规则冲突，我们需要一套管理 Agent 自身状态的版本控制系统。

Agent 为什么连自己调了几次工具都数不清？

上下文窗口本质上是一台极强的检索引擎，但原生缺失提炼与聚合层。规则写得再严，模型也数不清自己调用了几次工具。解析 Agent 状态栏机制（Status Bar），用确定性代码接管状态投影，让模型思考开销从线性膨胀收敛为恒定。

代码写得太顺手，我做出来的垃圾越来越多了

AI 把做工具的成本降到了零，也拆掉了程序员的刹车片。满磁盘的半成品玩具项目证明：写代码变容易后，验证和维护变得极贵。给冲动设个 48 小时冷冻期，才能把真正有价值的系统做出来。

让 Agent 自己审查代码，为什么经常越审越烂？

在封闭上下文中让 Agent 自审代码，把正确答案改错的概率远高于纠错率。多 Agent 协作生效的判据在于引入外部新信息。拆解 Proposer-Reviewer 架构、“模型无权批准完成”铁律，以及如何用上下文隔离防止 Token 爆炸。

选技术栈别再先问“我会什么”：系统的物理硬约束才是第一判据

技术选型的第一问正在从“自己会什么”变成系统的硬约束。Agent 抹平了语法和排错门槛，但不会替你做架构权衡。如果不把体积、内存、I/O 取舍变成显式约束，Agent 就会默认选最偷懒的实现。

Skills Over MCP 有用，但别急着搬走你的 SKILL.md

Skills Over MCP 能让使用方法跟着服务更新，但按需加载早已存在，自动更新也省不掉信任判断。哪些技能值得随连接分发，哪些继续放在仓库？

进程挂了 resume 回来，agent 却僵住了：log 才是 agent 本体

Claude Code 的进程挂掉后，resume 找回了对话，却丢了待批准的权限请求。要让 agent 真正恢复，持久化的不能只是一份 transcript，还要包括可重放的事件、工作区和副作用状态。

Agent 让每个人都有了翻译器，但团队不再说同一种语言

Agent 能解释旧代码，却补不回当初的取舍。一次看不懂旧模块的经历，让我决定把困在 session 里的设计理由带回代码库。

给 App 加个聊天框，不叫 Agent-first

Agent-first 的关键不是在 App 里塞聊天框，而是让 UI、Agent 与 MCP 共用同一套业务 action。先改一个高频动作，再决定入口长什么样。

Agent 跑得越快，越要提前告诉它什么时候停

Agent 长任务除了完成目标，还要写明三类停点：连续尝试无改善、缺少关键事实、即将越过范围。停下汇报，比继续猜更省时间。

Agent 写完前端，我要求它先自己点一遍

前端改完别急着接手。把浏览器自检写进 Definition of Done，让 Agent 先走核心路径、查 console、贴截图；人只接手最后的体验判断。

Agent 编程最隐蔽的盲区：你出了 loop，谁来替你摸 Tab 键

Agent 写的代码逻辑通、测试也过，用户的手却按不对地方：OpenCode 作者让 agent 处理焦点切换，它选了 f 键，而所有人的手指记得 Tab。agent 生成的是 plausible，不是 right；执行可以外包，品味判断不行。

AI 写完代码后，我只看这 5 个地方

Code Review AI 代码，传统清单全过，风险却藏在它替你做的默认选择里。五个该盯的落点：边界条件、错误处理、外部依赖的假设、状态一致性、权限边界——都是 AI 最容易自信做错的地方。十分钟把注意力收到这里，换半夜少接一次事故电话。

每次跟 agent 聊完，你把最值钱的东西丢了

跟 agent 聊完，代码进了 git，但踩过的坑、方案前提、下次先查什么这类工程判断没有容器，跟着 session 一起关掉了。解法：趁 context 还热让 agent 把非显然结论压成一两百字，丢进可搜索的 decisions 目录，下次 grep 就能调回来。

AI 写的测试全绿了？你在跟它一起自欺欺人

AI 同时写代码和测试，出题的和答题的是同一个脑子——代码里的隐含假设会照搬进测试，覆盖率 95% 也只证明内部一致。打破闭环只有一个方向：让测试的场景来自代码之外，由人从真实踩坑和业务理解里注入。

Spec 里最危险的，是你觉得不用写的部分

加缓存的 Spec 写了失效时间，没写"更新数据时清除对应缓存"——因为这太显然了。AI 不知道显然，Spec 写了什么它就做什么。越值钱的工程经验，越不会被写进 Spec；把"理所当然"变成白纸黑字，才是 Spec 质量的真正差距所在。

我让 AI 审了自己的代码，审了 10 轮

用同一把 prompt 对同一段代码做了 10 轮 AI code review，每轮都发现新问题——因为每次重构后代码形状变了，新接缝暴露新问题。AI 审 AI 需要稳定的标准、迭代的耐心，以及由人来决定"什么时候停"。

8 天 + 16 天 + 1 天：我不打算把 AI 编程跑成马拉松

AI 让你随时都能写代码，但这恰恰是新的危险——你永远离自己的代码太近。用人为的停顿替代以前的被动等待：8 天写代码，16 天只当使用者，1 天带着新眼睛回来审查。

跑一下试试，是 AI 时代最贵的验收方式

AI 生成代码的速度远超你阅读的速度，"跑一下试试"只能测到你想到的场景。真正有效的验收需要两层：先前置写验收标准让 AI 生成测试，再让另一个模型以"接手者视角"审查技术债——这十分钟能省掉三个月后那个"测试全过却线上出 bug"的噩梦。

不是不用 Spec，是你用错了——别告诉 AI 怎么做，告诉它什么不能做

好的前置文档不是给 AI 画一条路，而是画一个圈：目标在圈心，非目标和约束是边界，验收标准是终点线。圈内让 AI 自由发挥，"非目标"是投入产出比最高的一条，多模型交叉评审能在执行前填坑。

与 AI 共事一年，我从"甩手掌柜"变成了"掌舵人"

与 Coding Agent 协作将近一年的真实心得：从把 AI 当外包甩手、到凌晨被 oncall 叫醒的教训，到建立"先聊再写"、分步验证、保持怀疑的协作习惯，工程师的核心价值在于设计、判断与掌舵。

从"写代码"到"审代码"：AI 时代，开发者的能力迁移

Coding Agent 把开发者的核心职责从"写"迁移到了"审"：AI 两分钟生成 200 行，你要花 40 分钟把关，真正决定结果的是你前面的规划与后面的判断——架构取舍、需求拆解、代码嗅觉，这些能力在 AI 时代反而更值钱了。

SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码

Spec Driven Development 并没有消灭软件工程的难题，足够细的 spec 本质上就是另一种语法的代码；它还会把团队带回瀑布流，把不确定性藏在文档的完整性幻觉里，spec 永远覆盖不到的地方才是系统真正的盲区。