用 Fable 5 给旧项目做一次深度体检
手里有没有这种项目？
功能能跑，代码也没彻底烂掉。可你每次打开它，脑子里都会飘过几句话：
- 这里当初为什么这么写？
- 这个需求拖了半年，到底还能不能补？
- 那个偶发 Bug，是不是还在？
- 这套 Skill 已经跟不上现在的工作方式了吧？
平时赶新需求，根本没空翻旧账。现在有 Fable 5 这种能长时间陪你梳理上下文的工具，正适合狠狠干一轮。
别一上来就让它“优化整个项目”。这种话等于把方向盘交给一个刚坐进车里的副驾，容易翻车。更稳的办法，是把旧项目拆成三件事：深度 Review、补历史需求、更新 Skill。
开工前：别急着改，先给项目建一份档案
很多人 Review 旧代码，直接从某个文件开始读。读了两小时，越读越烦，最后只改了几个变量名。白忙。
先让 Fable 5 帮你建立“项目地图”。你需要拿到的不是一堆泛泛而谈的评价，而是能指导动手的清单。
把项目根目录、核心配置、依赖文件、主要入口和关键业务目录交给它，然后用这段提示词：
请阅读这个项目，并输出一份项目档案：
1. 项目用途，以及目标用户是谁
2. 技术栈、启动方式、构建方式
3. 核心业务链路，按“用户操作 → 接口/状态 → 数据变化 → 页面反馈”说明
4. 关键目录和关键文件的职责
5. 外部服务、环境变量、第三方依赖
6. 当前最可能出问题的模块
不要立刻修改代码。
不确定的地方请明确标记“待确认”，不要猜。
输出尽量引用具体文件路径和函数名。
这一步像搬家前先画户型图。你得知道承重墙在哪，才不会一锤子砸到水管。
项目档案里，重点盯住这 5 类信息
- 入口是否分散：页面、任务、定时器、脚本各自启动，后期极容易漏改。
- 配置是否混乱：密钥、环境地址、功能开关散落在代码里，换环境时很折磨人。
- 数据流是否绕路：一个按钮点下去，状态跨了四五层才回来，维护成本会越来越高。
- 异常是否被吞掉：
catch里空着，或者只打印日志。出问题时你只能靠祈祷。 - 测试是否缺位：核心逻辑没有测试，任何“顺手改一下”都可能变成线上事故。
深度 Review：别问“代码好不好”，要问“哪里会炸”
“帮我 Review 一下代码”这类提示，拿到的常常是一份礼貌但没用的废话：命名可以更规范、注释可以更完善、建议关注性能……看完只想关页面。
Review 要带着攻击性。目标不是夸代码整洁，而是找出会让你半夜爬起来修的问题。😅
把任务拆成多个专题，每次只让 Fable 5 查一类风险。
1. 查业务逻辑漏洞
请审查以下模块的业务逻辑。
重点检查：
- 边界条件是否遗漏
- 空值、重复提交、并发操作会发生什么
- 权限校验是否只做在前端
- 状态切换是否存在不可能恢复的分支
- 用户连续点击、刷新页面、网络中断时的结果
按“风险等级 / 文件位置 / 触发条件 / 后果 / 修复建议”输出。
每条建议都要基于具体代码，不要给通用建议。
一个很典型的场景：用户连点两次“提交订单”，前端弹了两次成功提示，后端却生成了两笔数据。这个坑不看并发和幂等，肉眼扫代码很容易漏掉。
2. 查安全和数据风险
请从安全与数据一致性角度检查这个项目：
- 是否存在敏感信息泄露
- 用户输入是否可能造成注入、越权或跨站脚本问题
- 删除、支付、发布等高风险操作是否可重复执行
- 数据更新是否需要事务或补偿机制
- 日志中是否打印了 token、手机号、身份证号等信息
请给出具体证据、影响范围和修复优先级。
别把“项目是内部用的”当护身符。内部系统往往权限更大，出一次问题更难看。
3. 查性能和资源泄漏
请检查以下代码是否存在性能问题或资源泄漏：
- 重复请求
- N+1 查询
- 不必要的大量渲染
- 定时器、事件监听、订阅没有清理
- 大文件或大列表处理不当
- 缓存失效策略不合理
请区分“必须修”和“暂时不用动”，并说明判断依据。
这里有个原则：别为了几毫秒去大改架构。真正该修的，是会让用户打开页面转圈十秒、会让服务器内存慢慢爬高、会让数据库被重复查询打爆的东西。
给问题排队：别把 Review 结果变成焦虑清单
跑完一轮 Review，问题可能有几十条。你要是看见一个修一个，很快就乱了。
建议建一张简单的整改表：
| 问题 | 影响 | 触发概率 | 修复成本 | 优先级 | | --- | --- | --- | --- | --- | | 重复提交生成重复订单 | 高 | 中 | 中 | P0 | | 列表页重复请求接口 | 中 | 高 | 低 | P1 | | 老组件命名不统一 | 低 | 高 | 中 | P3 |
排序逻辑很朴素：
- P0：可能造成数据错乱、安全事故、核心功能不可用。立刻处理。
- P1：用户天天能碰到，或者会持续消耗资源。本轮处理。
- P2：不影响主流程，但会拖慢维护。排进后续计划。
- P3：纯洁癖项。代码不顺眼，不等于现在必须动。
老项目最危险的时刻，往往不是它烂，而是你决定“趁机全部重构”。范围一失控，旧问题没修完，新问题先长出来了。
补历史需求：把一句“想加个功能”拆成可交付任务
那些以前没搞定的需求，大多不是技术上完全做不了，而是描述太模糊。
比如：“加一个导出功能。”
这句话根本没法直接开干。导出什么？谁能导？数据量多大怎么办？导出后有没有审计记录？Excel 还是 CSV？字段要不要脱敏？
把需求丢给 Fable 5 前，先用这个框架补齐：
需求名称：
目标用户：
用户要完成的动作：
入口位置：
输入内容：
输出结果：
权限规则：
异常场景：
验收标准：
暂不处理的范围：
示例：补一个数据导出需求
需求名称：订单列表导出
目标用户：运营管理员
用户要完成的动作：按筛选条件导出订单数据
入口位置：订单列表右上角
输入内容：当前筛选条件、导出字段选择
输出结果：生成 CSV 文件，并记录操作日志
权限规则：仅管理员可见；手机号只导出中间四位脱敏结果
异常场景：数据超过 10 万条时走异步任务；任务失败需提示原因
验收标准：导出内容与列表筛选结果一致；普通用户看不到入口
暂不处理的范围：不支持自定义 Excel 样式
然后再让 Fable 5 做技术拆解：
基于以下需求和现有项目结构，输出实现方案：
1. 需要修改的前端、后端、数据库文件
2. 接口定义，包括参数、返回值、错误码
3. 权限校验放在哪里
4. 大数据量导出的处理方案
5. 需要补充的测试用例
6. 实施步骤，按可独立验证的小任务拆分
不要直接输出完整代码。先指出现有架构中可能冲突的地方。
先要方案，再写代码。这个顺序很值钱。你能在写出三百行代码前，发现需求本身有坑。
让 Fable 5 写代码时，盯紧这三个动作
AI 写得快，错得也能很快。你需要把它当成手速极快的协作者，不是不用验收的自动售货机。
要它“小步提交”
一次只完成一个明确任务。
比如：
- 增加接口参数校验
- 写导出任务的数据查询逻辑
- 补一个权限拦截
- 增加前端下载状态
- 添加测试用例
每做完一步，都要求它说清楚：改了哪些文件、为什么改、如何验证。
只完成“为导出接口增加管理员权限校验”这一项。
修改前先说明现有权限链路。
修改后列出变更文件、关键逻辑和验证方式。
不要顺手重构无关代码。
要它给测试，而不是只给实现
没有测试的 AI 代码，就像刚洗完的车开进泥地。看着干净，稳不稳另说。
请为这次修改补充测试用例。
覆盖正常流程、无权限访问、空结果、大数据量、接口异常和重复点击。
如果当前项目无法直接运行测试，请给出最小可执行的人工验证步骤。
要它解释“没改什么”
这招很实用。
请确认本次改动没有影响哪些相关模块。
如果存在潜在影响，请明确列出，不要默认安全。
旧项目里，最怕“我只是加了个按钮，怎么登录页挂了？”
更新 Skill：把你重复说的话，变成团队能复用的规则
Skill 的价值，不在于堆一大段炫酷指令。真正有用的 Skill，是把你反复纠正 AI 的习惯固化下来。
比如你每次都要提醒它：
- 不要擅自改接口字段
- 先读现有类型定义
- 修改数据库前要给迁移方案
- 不确定需求时必须提问
- 输出代码时要附验证步骤
这些话说过三次，就该写进 Skill 了。
一个实用的项目开发 Skill 结构
# 项目开发规范
## 修改前
- 阅读相关模块、类型定义和现有测试。
- 不清楚业务规则时，列出问题等待确认。
- 不得凭空新增字段、接口或依赖。
## 修改中
- 保持现有目录结构和命名风格。
- 每次只处理一个明确任务。
- 高风险操作必须加入权限校验、异常处理和日志。
## 修改后
- 列出变更文件与修改原因。
- 提供测试用例或人工验证步骤。
- 标记潜在副作用与待确认事项。
## 禁止事项
- 不要删除未理解的旧代码。
- 不要为了“更优雅”进行大范围重构。
- 不要修改无关文件。
Skill 更新时，删掉这类废话
- “写出高质量代码”
- “遵循最佳实践”
- “确保性能良好”
这些话谁都会说，执行时没有边界。
换成能检查的规则：
- 新接口必须定义错误码和权限策略。
- 涉及金额、库存、状态流转时，必须说明幂等方案。
- 修改查询逻辑时，必须说明分页、排序和数据量上限。
- 改动核心链路时，必须补回归测试清单。
规则越具体，输出越稳。模糊要求只会换来模糊结果。
一晚冲刺的安排：别熬成“看了很多，没落地”
真打算晚上狠狠干，建议按这个节奏来：
第 1 小时：建立项目地图
- 跑通项目
- 让 Fable 5 输出项目档案
- 记下核心链路和未知区域
第 2～3 小时：集中做风险 Review
- 业务逻辑
- 安全与权限
- 性能与资源
- 测试缺口
把发现的问题塞进整改表，别在这里陷入修代码。
第 4～5 小时：拿下 1 个 P0 或 2 个 P1
控制范围。修完就验证。不要看见旁边一块代码不顺眼，又开一个新坑。
收尾 30 分钟：沉淀 Skill 和项目记录
把今天踩到的坑写下来：
- 项目有哪些隐性规则
- 哪些模块不能轻易碰
- 哪种提示词效果最好
- 哪些检查项下次必须自动跑
这 30 分钟很容易被忽略，却决定你下次是不是还要从零摸索。
常见翻车点清单 ⚠️
- 一口气让 AI 重构整个项目：改动面太大，定位问题会痛苦到怀疑人生。
- 没跑项目就开始改：基础环境都没确认，后面报错根本分不清是旧问题还是新问题。
- 把 AI 的判断当事实：它能帮你发现线索，证据仍要回到代码、日志和实际运行结果。
- 需求没有验收标准：写完才发现“你理解的导出”和产品想要的导出不是一回事。
- 只修功能，不补回归验证：今天修掉重复提交，明天一个样式改动又把拦截逻辑删了，太亏。
- Skill 写得像口号：规则无法验证，就等于没有规则。
你真正要拿走的成果
一轮旧项目整理做完，别只满足于“修了几个 Bug”。至少留下这四样东西：
- 一份项目地图，新同事看完能知道从哪下手。
- 一张按优先级排序的技术债清单。
- 一批可验证、可上线的历史需求改动。
- 一套更新后的 Skill，把重复劳动挡在下一次对话之前。
旧项目不是包袱。它更像你以前欠下的一堆小账。
趁工具顺手、注意力还在，挑最疼的那几笔先还掉。明天再打开这个项目时，你会轻松很多。
