软件工程10年经验被裁后，用AI重构工作流的真实体感

从业十年，经历过大厂的繁荣也经历过被裁员、倦怠期（Burnout）这种至暗时刻，在重新找回节奏的过程中，我发现现在的开发环境和五年前完全不同了。之前的习惯是依赖深厚的领域知识和手动查文档，但现在我尝试将 AI Agent 深度整合进我的重建计划（EFC），实测下来，开发效率的提升并非线性，而是取决于你如何定义“工作流”。

在尝试用 Claude Code 配合本地环境进行代码重构时，我遇到了一个非常典型的上下文丢失问题。当我要求它重构一个涉及三个不同模块（Auth, Payment, UserProfile）的跨文件逻辑时，AI 经常在修改完第二个文件后，忘记了第一个文件的具体变量命名，导致编译报错 ReferenceError: X is not defined。

为了解决这个坑，我摸索出了一套强制上下文同步的实操方法，不再直接下达“重构这个功能”这种模糊指令，而是采用分段式确认：

一、 建立上下文快照
先让 AI 读取相关文件并输出一个简短的依赖映射，强制它在内存中建立索引。

# 示例指令
/read src/auth.ts src/payment.ts src/user.ts
Summarize the current data flow between these three files. List all shared variables.

二、 原子化修改 + 校验
每次只允许它修改一个文件，并在修改后立即运行测试脚本。

# 针对具体函数的重构指令
Refactor the calculateTax function in payment.ts to use the new taxRate from auth.ts. 
Wait for my confirmation after you write the code, then run 'npm test payment'.

三、 强制同步状态
如果涉及多文件变更，在每步操作结束后，要求它更新一个 .ai_context 的临时文本文件，记录当前已修改的 API 接口定义。

实测下来，这种“慢即是快”的策略将我的 Bug 修复率从之前的 60% 提升到了 90% 以上。响应时间虽然因为增加了确认步骤而延长，但避免了在错误方向上浪费两三个小时的调试时间。

关于 AI 辅助开发的另一个认知偏差是：很多人认为 Prompt 越详细越好。但在实际的工程实战中，过长的提示词反而会稀释模型的注意力（Attention）。我现在倾向于使用“指令集+状态同步”的模式。比如在处理复杂逻辑时，我会定义一个简单的状态机：

• State: ANALYSIS（分析阶段，只出文档，不出代码）
• State: IMPLEMENT（实现阶段，严格执行文档）
• State: VERIFY（验证阶段，运行测试并对比预期）

这种结构化的沟通方式比写一段 500 字的保姆级 Prompt 要高效得多。对于那些同样在经历职业转型或尝试用 AI 提升生产力的开发者，建议不要试图一次性让 AI 完成大任务，要把任务拆解到它无法出错的原子级别。

整个重建过程让我意识到，AI Agent 真正的价值不在于替代写代码，而在于它能扮演一个极其耐心的“橡皮鸭”，在通过不断的 Read -> Plan -> Execute -> Verify 循环中，帮我们把混乱的旧逻辑梳理清楚。