企业官网建设流程全解析

AI 时代不少人觉得做一个应用应该很简单：需求说清楚，让 AI 写代码，跑起来就完事。但真正带过项目的人都知道，把一句话需求变成能稳定使用的应用，中间的落差大得惊人。我最近按“文档驱动 + 实测修订”的思路，把一个内部工具从模糊想法一路落到能交付的状态，整条路径对个人开发者和两三人的小团队都很有参考价值。这篇文章就把这条路径完整拆开讲，不绕弯子，直接说怎么做、为什么这么做、以及实测时最容易踩的坑。

1. 项目第一步：把模糊需求翻译成文档

1.1 为什么第一步是文档而不是代码

很多开发者拿到需求后的第一反应是“赶紧搭环境、写接口、接模型”。我建议先忍住。AI 写代码的能力越强，越容易出现一个错觉：代码写得快 = 项目推进得快。实际上，AI 只会帮你实现“你以为的需求”，不会帮你确认“对方真正要的需求”。这句话是我做这个项目最大的教训。

举个例子。某业务方提了一句：“帮我们把会议纪要从录音里整理出来。”这句话的可解释空间非常大——是要全文转写？还是要结构化摘要？是提取待办事项？还是生成周报素材？如果连“纪要到底是什么样”都没定义清楚，开发进行到一半必然来回返工。文档驱动的核心作用不是走流程，而是在动手前把“大家嘴上说的需求”固化成白纸黑字，让业务方、开发者在同一个版本上对话。

我这里的“文档”不是传统意义上几十页的 PRD，而是一页纸的需求说明书。重点是“一页纸”，因为太长的文档没人看，写的人也容易陷入细节。只要把关键信息说清楚，这份文档就能成为后续所有开发、测试、验收的依据。文档先行的本质，是让需求在编码之前先被“怼”一遍：有哪些漏洞、哪些冲突、哪些根本没法验收，全部在这一步暴露出来。

1.2 需求文档模板：七要素一个都不能少

我整理了一个内部模板，每次做工具类项目都直接套用，省时也不容易漏项。先说模板，再拿这个会议录音处理项目举例。

会议录音处理项目填完大致是这样：背景是项目组每周要开两三次会，整理纪要约半小时，效率低；用户角色是会议组织者和项目助理；核心流程是上传录音文件到工具，自动转成文字，再整理成结构化纪要并提取待办；数据来源是 MP3 或 WAV 文件，输出是一份 Markdown 纪要；边界清单写得很明确——本期不做实时转写、不做移动端、不做多语种、不做历史数据迁移；验收标准写在下一节；依赖则是语音转写模型的识别质量和摘要模型接口的稳定性。

这里最容易被忽略的是“边界清单”。我见过太多项目挂在一个很小的附加需求上，比如“顺手把这个音频也能转成字幕吧”“顺便支持一下导出 PDF 吧”。每个“顺便”背后都是额外的工作量和隐藏的 bug。边界清单最大的价值，是在需求蔓延时让你有一句话可以拒绝：“这不在本期范围内，如果要做，我们另开一个需求记录。”

1.3 用“用户故事 + 验收标准”锁住边界

第四节验收标准，是很多 DIY 项目最容易写空的地方。“输出质量要好”“处理速度要快”这种话等于没说。我的做法是把它拆成可测量的描述。

先写用户故事，格式是：作为某个角色，我希望做什么，这样我就能得到什么结果。这个项目里的用户故事是：

作为项目组会议组织者，我希望上传一段会议录音后自动拿到一份结构化纪要，里面有讨论要点、明确结论和责任人待办，这样我就不用再花半小时手动整理会议记录。

用户故事只解决“方向”问题，验收标准才解决“到位没有”的问题。我在这份文档里写的验收标准包括：

• 输入音频格式支持 MP3/WAV，单段时长不超过 90 分钟；
• 输出一份 Markdown 格式纪要，包含会议主题、参与人、讨论要点、明确结论、待办事项五部分；
• 一段 60 分钟音频的处理时间不超过 12 分钟（也就是不超过音频时长的 1.2 倍）；
• 从测试样本中人工核对，关键结论和待办事项的提取完整率达到 90% 以上；
• 运行环境直接放在本地 Windows 工作站上，不依赖外部云服务。

你可能会问：90% 怎么测？待办提取“完整”怎么定义？这就是后面“实测修订”环节要干的事——先定义可测的指标，再用真实的测试数据逐条验证。没有指标的验收标准是空话，有指标但后面不去测，同样是空话。

2. 技术选型与 AI 辅助开发的边界

2.1 技术选型：稳定压倒一切，不要为了 AI 而 AI

技术选型这件事被 AI 时代严重低估了。很多人觉得既然有 AI 模型，那整个工具都应该围绕“最聪明”的方案搭。我的原则恰恰相反：能用简单方案解决的，绝不上复杂方案。技术栈的选择优先级是：团队熟悉程度 > 部署维护成本 > 迭代速度 > 功能上限。

这个会议录音工具的技术栈没用什么新奇东西：后端用 Python 的异步 Web 框架，数据库用一个轻量级嵌入式库，语音部分接入开源语音转文字模型，整理纪要和提取待办的部分接大语言模型服务的 API。选择这套方案的逻辑很有代表性：

第一，团队对 Python 和异步框架最熟，三行代码能解决的问题不需要换一门语言去“练手”。第二，语音转文字这部分主要涉及隐私，项目数据里有不少客户信息和内部决策，把音频送去外部服务始终有顾虑，所以选择本地离线转写。第三，语言模型摘要部分选择 API，因为本地部署一个小模型效果达不到要求，而 API 在摘要和结构化输出上表现更稳，成本也完全可接受。

我还主动放弃过一个“看起来更先进”的方案。最初讨论时有人提议给这个工具加一套知识库检索，做 RAG 增强生成，理由是摘要会更“懂”项目背景。后来分析发现，单个会议的内容与历史知识库的关联其实很低，会议纪要不依赖长期记忆，把当前音频转写出来的文本直接塞进上下文就够用了。RAG 解决的是“模型没看过的东西怎么引用”的问题，这个场景没有这个需求。为了用 RAG 而用 RAG，只会增加部署复杂度和排查难度。

2.2 AI 写代码的能力边界在哪里

这个项目从骨架搭建到脚本改造，确实大量用了 AI 编程辅助。但用下来，我心里有一条很清晰的边界：AI 可以写“确定性”很强的代码，但“业务规则”必须由人来定。哪些交给 AI 比较放心？接口的骨架代码、数据库增删改查、前端页面基础框架、正则提取、常见的单元测试，这类场景输入输出关系明确，让 AI 生成效率极高。

哪些不能放手？业务规则判定、提示词设计、异常链路处理、数据安全边界、验收标准的拆解。这几类问题一旦出错，不是代码 bug，而是方向性错误。

举两个项目里真实遇到的例子。AI 生成的上传接口没有做文件大小限制，我第一次测试传一个 100 多 MB 的录音文件，接口直接超时，前端傻等半天没反应。另一个例子是 AI 生成的摘要调用没做超时和重试，某家大模型接口偶尔响应很慢，结果整个任务直接崩掉，而不是等待后重试。这类问题代码层面很好修，但如果你完全把代码放心交给 AI，不去审查边界条件，你根本不知道它默认帮你“略过”了多少细节。

所以我后来给自己定了一条规矩：AI 生成代码后，要把它当成新同事交上来的代码做代码评审，而不是直接信任。我看的重点就是四件事：有没有校验输入、有没有处理超时/失败、有没有考虑并发情况、数据库字段定义有没有和文档对齐。这一步看似多花时间，实际能省掉后期大量排障成本。

2.3 从文档到首个可运行版本的最小路径

文档写完、技术栈选完，接下来关键是“多快能看到一个能跑的东西”。我强烈建议走最小可行链路，不求功能全，只求通。

当时我定的第一个版本路径是：上传音频 → 转文字 → 调大模型生成纪要 → 页面展示。只有这四条链路，没有用户管理、没有历史记录、没有批量处理。所有多余功能都在边界清单里被砍掉了。

实现顺序上也很有讲究。先定义清楚数据模型，一张表存会议任务，一张表存转写结果，一张表存生成的纪要。数据结构对了，后面加功能才不别扭。然后立刻用一段两分钟的测试录音跑通全链路——注意，是两分钟，不是两小时。这一步的目标是打通集成，暴露“文件传不上来”“模型返回格式不是我要的”这种最要命的接口问题，而不是追求识别效果。

我习惯把这个最小版本的控制在一个工作日内完成。先看到东西，再谈细节。因为只有跑起来，业务方才能对着一个真实产物说“我要的不是这个”，那个反馈比任何文档评审都有效。这也是“实测修订”真正开始的地方。

3. 实测修订：把“能用”变成“好用”

3.1 第一轮实测：别信“看着没问题”

系统刚跑通的时候，我用开发时用的干净音频自测，效果出乎意料地好。纪要结构清晰，待办提取准确，我当时差点直接拿给业务方信心满满地演示。还好在演示之前，我做了替换成真实数据的第一轮实测，结果很快就打脸了。

真实会议录音和测试音频完全不是一回事。项目组的例会录音里有四五个人同时说话、有大量“嗯”“对吧”这类口语词、有中英文混说的技术词汇、还有不时响起的手机提示音和键盘声。这种输入一进去，语音转写模型直接露怯，错别字连篇，大模型摘要拿到的就是一份错漏百出的草稿。更别提原定的“不支持英文”边界，在实际场景里完全站不住脚——项目组开会一半名词都是英文。

从那天起我给自己定了一个规矩：上线前的自测必须使用真实采样数据，不能只用干净样本。我列了一个测试样本计划表，至少覆盖七种输入形态：

这些样本不要求很多，十来个已经能暴露 80% 的问题。实测的价值不在于证明系统好，而在于尽快找到“系统其实还不满足需求”的证据。

3.2 修订闭环：问题记录、归因、回归三步法

第一轮实测之后，问题会像开闸一样涌出来。如果没有一套记录规则，很快就会发现：昨天改的 bug，今天忘了为什么改；上周调过的参数，这周又被人调回去。我用的方法非常简单，把每个问题按“现象 / 复现步骤 / 原因假设 / 修改方案 / 回归结果”五行记录在一张共享表里。

举两个真实案例。第一个问题是长音频处理超时。现象是 80 分钟录音传上去之后，前端永远在转圈，等半小时也没出来。复现步骤很稳定，任何超过 30 分钟的音频都会卡死。原因假设是后端同步调用语音转写模型，转写流程阻塞了整个请求线程。修改方案是把转写改成后台任务，加上任务状态查询接口，前端轮询进度。回归结果是 90 分钟音频稳定输出，耗时约 14 分钟。这个案例说明，很多时候问题不在“模型不够聪明”，而在工程链路设计。

第二个问题很有代表性：待办提取漏项。现象是人工核对纪要时，发现“这个方案下周要出结果，由数据组的同事跟进”这种典型口语表达没有被提取为待办事项。原因是提示词里只写了“提取待办事项”，模型倾向于抓“负责”“跟进”“完成”这类关键词，遇到承诺式、隐式表达就漏。修改方案不是改代码，而是改提示词，明确加了一句话：“口语中表达承诺、安排、跟进意图的语句，即使没有出现‘待办’二字，也应视为待办事项。输出必须包含责任人、事项、时间节点三项，缺少信息时标记为待确认。”回归验证时用之前所有漏项样本重跑，提取完整率从大约七成提升到了九成以上。

这一步有个必须坚持的原则：每一步修改都要回归重跑之前全部相关用例。不是只验证你改的那一条，而是把之前跑过的几条一起跑一遍。否则很可能是修好了漏项，却把之前正确的摘要格式改坏了。回归测试在个人项目里最容易偷懒，但它恰恰是“实测修订”里最不该省的一环。

3.3 实测数据反过来更新文档

文档驱动不等于“文档写完就定死了”。真实项目里，文档和实测是双向修订的关系——实测发现的情况反过来要求文档修正。这是我在这个项目中体会最深的一点。

一开始文档里写的边界是“本期不支持英文”。第一轮实测就发现项目组开会一半内容是英文技术词汇，如果硬按边界执行，这个工具就没有使用价值。于是我把边界从“不支持英文”改成“支持中英混说，以中文输出为主，保留英文术语原文”，这个修改直接影响了转写模型的参数配置和摘要提示词的设计。还有一次，业务方看到输出纪要说“原始音频文件你们会保留吗”，我说“任务结束就删”，业务方马上反对，说“后续还要核对原始数据，必须保留至少三个月”。这又导致数据存储策略的重新设计。

你看，这些需求都不是开发前业务方能一次讲清的，而是看到真实输出后才意识到。所以我在文档里加了一个“版本记录”小节，每次变更记录四件事：变更时间、变更内容、影响范围、谁确认的。表格不用复杂，但一定要有。这件事的价值在于，几周后当有人问“为什么这里支持英文了”，你能翻开记录看到是某次实测后的需求补充，而不是凭记忆去猜。

3.4 修订节奏：小步快跑，别憋大招

实测修订的节奏，我说得非常直白：一次只改一到两个点，立刻去跑测试。不要攒十个问题集中改一轮再统一验证。原因很简单，多个问题改在一起会互相纠缠，出了问题很难定位是哪一次改动引入的。

我把一个迭代单位控制在半天：半天内完成“改代码 → 跑三到五条用例 → 记录结果”这一整个循环。比如今天目标是解决长音频超时，那就只改后台任务和进度查询，改完立刻拿 80 分钟样本跑，跑完记录。下半天再处理待办提取漏项，只改提示词，改完立刻用旧样本验证。这样做进度看起来很慢，实际上收敛非常快。因为每个循环都有明确输出，不会出现“改了一整周，但不知道现在系统处于什么状态”的情况。

实测修订本质是一个反馈回路。回路越短，系统收敛越快。AI 时代尤其如此，因为很多环节的不可控性都集中在模型输出上，你只有快速试错才能知道模型在真实输入下的行为到底是什么。

4. 实测中的典型问题和排查实录

4.1 高频问题速查表

把整个项目实测过程中遇到的高频问题整理成一张速查表，后面再做同类工具可以直接对照排查。

这张表最想强调的一行是“模型输出永远不可假定一定正确”。大语言模型在结构化输出上已经相当可靠，但“相当可靠”不等于“每次可靠”。代码里必须加一层解析和校验，格式不对就重试，重试还不行就进入人工标记。这层防护在个人项目里很容易被省略，省略的代价就是某次输出涨出一个奇怪字符后，整个页面直接白屏。

4.2 需求变更时文档如何同步

项目进行到中后期，业务方开始习惯用这个工具，新想法会源源不断地冒出来。最怕的不是变更本身，而是变更没有记录、没有评估、直接改代码。

有一次业务方在演示会后提了一句“纪要里帮我们把相关链接也带上，像我们之前用云盘的那种链接”。开发同事手快，当天就把这个功能加上去了。结果三天后复盘时，没人说得清这个字段是怎么定义的，哪些链接应该抓、哪些不抓，格式规范是什么。最后只能翻代码去猜，浪费的时间比早先写一行文档多得多。

所以我在项目里立了一个不说出口但严格执行的规矩：口头需求一律先落到文档的变更记录里，再动代码。变更记录至少写清楚：提出时间、提出人、变更内容、影响范围、处理优先级。如果变更会影响验收标准，还必须同步改掉验收标准里对应的描述。比如“支持中英混说”这个变更，就明确影响了验收标准里“输出语言”的描述。没有这个过程，文档驱动就会退化成“文档只是装饰”。

4.3 三个值得长期坚持的实操习惯

最后分享几个我在这个项目里养成的习惯，不算新奇，但长期坚持下来非常有用。

第一个习惯是保留每次实测的现场。日志、截图、输入样本、输出结果，都按日期归档。表面上看是占了一点存储空间，实际上每次出问题时，都能翻出“上周那次输入同样的音频跑出来是什么结果”，对比一下就能快速判断是新改代码引入的问题，还是某个外部依赖变了。排查效率提升不是一点半点。

第二个习惯是测试用例版本化。每次新增需求或修改验收标准，先补测试用例，再改代码。用例就是需求的可执行版本。某个新功能上线后，旧用例还能跑通，就说明没有破坏原有行为。这个习惯让“回归测试”变得不那么痛苦，因为你不用每次临时想测什么，测试策略早就写在需求变更里了。

第三个习惯是灰度交付。工具开发到基本稳定后，我先只让一个每天开会的同事试用一周，把使用中的真实反馈记录下来，再调整一轮，之后才推给整个项目组。不要一做好就全员铺开。小范围灰度可以把“用得别扭”的问题控制在影响面最小的阶段，等大家真正开始依赖这个工具时，它已经是一个经受过真实使用检验的版本了。

我自己做这个项目的体会是，AI 时代做应用，编码能力已经不再是最大的瓶颈，对需求的理解、对输出的验证、对迭代节奏的把控，才是真正拉开差距的地方。文档驱动和实测修订看起来是很朴素的工程方法，但恰恰是它们把“AI 生成的代码”和“能落地的应用”这两件事之间的裂缝补上了。最后再分享一个小技巧：在需求文档里专门留一个“已知问题”小节，把当前没解决、没确认、有疑问的事项全部挂在那里，每次评审先看这一节。这个不起眼的动作，能替整个项目省掉大量来回试探的无效沟通。