ARTICLE · 1203085
180 份设计文档、812 个代码文件:我用 AI 在 3人天内摸清一个陌生系统
你有没有遇到过这种项目：系统要加新功能，可它除了一堆文档，没人能说清它到底是干什么的？
这时你从哪下手？读文档？翻代码？还是先问 AI？
最近我就接手了一个这样的案例：一套零售系统。现有资料有 180 份设计文档、812 个代码文件、6 大模块、54 个菜单，却找不到一个人能把它从头说到尾。
按老办法要 15～20 人天，这次我只用了 3人天。下面说说我是怎么做的。
一、接到陌生系统的需求，最难的是什么？
真正难的，不是某段代码看不懂，而是你根本不知道自己还缺什么。
从头读设计文档？逐个点菜单？还是直接看代码？无论选哪条，只要没人先给你一张完整的系统地图，你都会一头扎进细节里打转。资料看了不少，脑海却拼不出全貌。
需要说明：15～20 人天是传统方式的预估，3.5 人天是本次 AI 辅助实践的实际耗时，两者并非严格控制条件下的对照实验。这个结果只反映本次工作的情况，不代表所有系统调查都能达到同样效率。
这次实践让我意识到一件事：面对陌生系统，AI 的真正价值，是帮你从分散的信息中快速建立系统全貌。
那么，这件事具体怎么做？
二、第一步：先让 AI 帮你建立系统全貌
面对陌生系统，最容易犯的错，是一开始就埋头研究细节。
文档挨个过一遍，资料看了不少，脑海却仍没有一张完整的系统地图。
为什么？因为你还没建立整体认识，就陷入了局部调查。
这次，我先关注三个问题：
这个系统整体上是做什么的？ 系统包含哪些业务模块和功能？ 模块、菜单之间存在怎样的关系？
有了明确目标，再让 AI 梳理已有的文档和代码。
与其让它 "总结所有文件"，不如围绕具体问题持续提问，例如：
・根据现有资料，归纳系统的业务定位和主要功能。
・按业务模块整理功能范围，并梳理与系统菜单的对应关系。
・对文档未说明的功能，继续寻找相关代码线索。
・对不同资料描述不一致的内容，列出待核实事项。
关键是：先明确自己想了解什么，再让 AI 围绕目标组织信息。
AI 整理出初步结果后，我再继续追问：哪些功能还不清楚？哪些模块关系需确认？哪些结论有依据，哪些只是推测？
这样，分析就从漫无目的地阅读，变成了围绕问题逐步建立认识。
当然，AI 整理的概况不能直接当结论。关键业务规则、模块边界和功能关系，仍要回到原始文档或代码核实。
三、第二步：让 AI 辅助调查代码
了解整体结构后，要解决的核心问题是：这次加新功能，究竟影响哪些功能？
没有整体认识，代码调查容易陷入两个困境。第一，不知从何入手，只能逐个文件找。第二，只发现局部功能，却看不到它与其他模块的关联。
AI 能让调查更有方向。围绕已识别的功能，继续追问：
・某个菜单对应哪些业务功能？ ・相关功能在文档和代码中分别体现在哪？ ・与本次需求相关的逻辑，可能涉及哪些模块、功能或数据？ ・哪些有明确依据，哪些仍需调查？
这些问题的价值，是帮你从大量资料中找出线索，逐步缩小调查范围。
但要注意：AI 指出的代码位置，只是线索，不等于最终改修范围。某段代码涉及相关逻辑，不代表它一定要改；AI 没发现关联，也不代表它不受影响。最终，仍要结合需求条件、业务规则和实际逻辑逐项判断。
AI 真正的作用，是帮你更快找到调查方向，而不是替你决定哪些代码必须改。
四、第三步：持续提问，把 "不知道" 变成调查事项
分析陌生系统，还有一个容易被忽略的问题：你不仅可能找不到答案，还可能根本不知道自己遗漏了什么。
系统缺少完整说明，又没人能讲清业务时，只读大量文档和代码，不等于真理解了系统。
这时，持续提问很重要。围绕系统概况，继续追问：
・某个功能的业务目的是否明确？ ・文档中的规则，能否在代码里找到对应？ ・需求涉及的业务条件，是否还有未识别的例外？ ・哪些结论有支撑，哪些仍有不确定性？
AI 能帮你发现知识缺口，把模糊问题整理成具体调查事项。
以本次零售系统为例。AI 先梳理出系统全貌：6 大模块中，商品资料、门店收银、销售、结算 4 个模块与本次需求直接相关；库存的成本核算口径，文档里没有明确说明。
于是，我没有让 AI 直接给出一个 "看似合理" 的答案，而是把问题列成待确认事项，交给业务方核实：
・历史单据是否按旧规则保留？ ・成本核算口径如何处理？ ・是否存在文档未覆盖的自定义扩展点？
这样，"这里不太明白" 就变成了具体的调查任务。
AI 帮你发现问题，人负责判断问题的重要性，并找到可靠答案。
五、第四步：把分散信息整理成可用的分析成果
理解系统、调查代码、识别疑点，最终都要落到一个目标：形成能支持后续工作的成果。
对本次零售系统来说，我需要掌握的不是某一份文档或代码，而是系统概况和需求影响范围。
AI 帮我整理出这样一份成果（示意）：
待确认事项：
・历史单据是否按旧规则保留 ・成本核算口径如何处理。
・是否有未被文档覆盖的自定义扩展点。
这份清单的每个候选点，都挂着 "文档线索＋代码线索＋影响等级＋状态"。有依据的标 "已确认"，只有推测的标 "待确认"。
随后，再由分析人员检查：结果是否完整？关键结论是否有依据？待确认事项是否标清？
这一步很重要，一份结构完整的文档，不代表分析做对了。真正有价值的成果，应当说明系统是什么、需求影响哪里、判断如何得出。
本次实践，我用 3人天完成了这份前期梳理。
这里说的是系统理解和影响调查，不包括改修设计、开发与测试。
六、AI 辅助需求分析，有哪些边界不能忽视？
这次实践让我看到 AI 的价值，但我不认为，把资料交给 AI，复杂系统就会自动变透明。实际工作中，至少有四个方面要注意：
资料安全不能忽视。 设计文档和代码可能含企业信息。能否上传，必须符合企业的数据分类、保密要求和工具使用规定。不能为了效率，忽略信息安全。 关键结论必须可追溯。 系统概况、业务规则和影响范围，都应尽量对应到具体文档、代码位置或可信来源。没有依据的内容，标为待确认，不当事实。 候选范围不等于最终范围。 影响分析既要避免遗漏，也要避免无谓扩大范围。最终，仍需结合业务规则、需求条件和实际代码判断。 不能只追求速度，忽略质量。 如果前期很快，后续却因理解错误大量返工，比较前期耗时就没有意义。除了时间，还应关注成果完整性、结论可追溯性，以及后续开发测试的反馈。
AI 能更快处理信息，但结论的正确性和完整性，最终由人负责。
写在最后：真正的提效，是更快找到值得调查的问题
回顾这次零售系统的实践，我最大的感受是：面对没人能讲清的陌生系统，先建立整体认识，再带着明确问题深入细节，比一开始就逐个文件埋头调查更重要。
6 大业务模块、54 个系统菜单、180 份设计文档、812 个代码文件。借助 AI，我通过持续提问，把分散资料转化为系统概况、功能结构和影响范围的分析线索，最终用 3.5 人天完成这次前期调查。
这次经历也让我更明确：AI 的价值不只是生成内容，而是帮你更快理解复杂信息、发现未知问题、组织调查路径。
当然，AI 不能替代业务理解，也不能代替代码核查和最终判断。但当你知道要问什么、如何验证答案、怎样整理成可靠成果时，AI 就能成为需求分析中真正有效的助手。
如果你也要分析一个陌生系统，不妨从三个问题开始：
・这个系统整体上是做什么的？
・它包含哪些业务功能，各部分之间有什么关系？
・当前需求可能影响哪些功能，判断依据是什么？
先让 AI 帮你建立全貌，再带着明确的问题深入调查。
真正有效的 AI 应用，不是让 AI 替你做所有思考，而是让你更快找到值得思考的问题。
留言互动
如果你在工作中遇到一个陌生系统，没有人能完整介绍它，你通常会从哪里入手？
A. 先读设计文档，理解业务功能 B. 直接调查代码，追踪具体实现
C. 借助 AI 先梳理系统全貌，再深入调查 D. 先找业务人员访谈，补齐背景信息
欢迎在评论区留下你的选择，也欢迎分享你使用 AI 进行需求分析或系统调查的真实经历。
