企业官网建设流程全解析

一条指令换不来一个产品。真正决定交付质量的，不是你用哪个模型，而是你在模型动手之前，把多少不确定性提前收敛掉了。

一、被高估的「一句话开发」

装好 Codex 或 Claude Code，敲一句「给我做个电子书阅读器」，几分钟后确实会有一堆代码躺在目录里，甚至能跑起来。于是很容易得出结论：AI 编程已经解决了。

但只要你真的把这个流程走完几次，就会遇到三类反复出现的落差：

1. 方向错。你脑子里想的是一个安静的纯文本阅读器，AI 交付的是一个带书架、云同步、社交书评的「阅读平台」。功能都实现了，但没有一个是你要的。
2. 细节错。界面能用，但交互处处别扭：翻页方式不对、字号调节藏在三级菜单里、导入文件后要手动刷新。
3. 质量差。跑十分钟就崩，边界情况一碰就炸，改一个 bug 冒出三个新的。

这三类问题看起来是模型能力不足，本质上却是信息与约束不足。模型的代码生成能力已经远超大多数人的手写速度，真正的瓶颈在于：

• 你没把「想要什么」说清楚，模型只能靠概率补全你的意图；
• 你没给它可回滚的安全网，于是每次修改都是不可逆的赌注；
• 你没定义「什么叫做完了」，于是它写完就交差，验证成本全部转移给你。

所以，用 AI 做产品的正确姿势不是「更会写提示词」，而是给一个高能力、低确定性的执行者，搭一套能约束它的流程。下面这套流程，我会用一个具体项目走完整遍：一个叫「马克阅读」的极简电子书阅读器。每一步我都会说明它到底在解决什么问题、什么时候可以省、什么时候千万别省。

整体流程是这样的：

选 Agent → 环境搭建（Git + AGENTS.md）→ 产品设计（讨论 → 砍需求 → 设计文档） → Demo 验证 → 技术方案 → 任务拆解 → 分段实现 → 验收测试 → 迭代

看起来步骤不少，但真正需要你「动脑」的只有前半段，后半段主要是让 AI 按你定好的轨道跑。

二、第 0 步：选一个编程 Agent，然后别被它绑住

现在主流的编程 Agent 有 Codex、Claude Code，此外还有 OpenCode、Pi、Cursor 等一批工具。如果没有特殊偏好，Codex 是一个安全的默认选择：功能覆盖比较完整，没有明显短板。

模型来源上有两条路：

这里有个容易被忽略的判断：Codex 是壳，模型是芯。大部分主流模型都能接进去用，所以「选 Agent」和「选模型」是两个可以分开决策的问题。你完全可以用 Codex 的工作流 + 国产模型的成本结构。

更重要的一条原则是：尽量不要依赖某个 Agent 的独有功能。本文后面涉及的所有操作——初始化仓库、写项目规范文件、讨论设计、生成 demo、分段实现——都是通用能力。你换成 Claude Code、Pi 或别的工具，流程一模一样。工具会迭代、会涨价、会被更好的替代品取代，但流程本身是可迁移的资产。把工作流建立在通用能力上，你的迁移成本才接近于零。

三、第 1 步：环境搭建只有两件事

很多人以为环境搭建是装依赖、配环境变量、选框架。在 AI 编程语境下，真正必须做的只有两件事：Git和AGENTS.md。

3.1 建目录、建项目

先给产品建一个专属文件夹，只放这个项目的代码。以电子书阅读器为例，目录就叫mark-reader（项目名「马克阅读」）。然后在 Codex 里新建项目，类型选本地，把这个文件夹加进来。

这一步看着琐碎，但它定义了 Agent 的工作边界。一个干净、独立、单一职责的目录，能显著减少 Agent 读到无关文件、误改其他项目的概率。不要把新项目塞进一个已经有五个项目的杂物文件夹里。

3.2 Git：给 AI 装一张安全网

接下来让 Agent 把当前目录初始化为 Git 仓库。指令可以极其朴素：

帮我把当前目录初始化为一个 Git 仓库。

然后自己在终端验证一下，不要只信 Agent 的口头汇报：

cdmark-readergitstatus

只要正常返回分支和文件状态、没有报错，就说明目录已经被 Git 托管了。

Git 的作用在 AI 编程里被放大了不止一个量级。手写代码时，你对每一行改动都有心理模型，出问题大致知道该往哪看。而 Agent 一次可能改动十几个文件、几百行代码，你没有逐行读过。这种情况下，版本快照就是你唯一可靠的撤销键。

它带来三个具体收益：

• 一键回退。第 5 次迭代把代码改乱了，直接回到第 4 次的状态，不需要让 AI「再改回去」——让 AI 修复自己搞乱的代码，往往越修越乱。
• 可读的变更历史。每个 commit 对应一个功能，等于给项目自动生成了一份开发日志。
• 给 Agent 的定位线索。当你说「上一版还好的，这一版坏了」，有 commit 历史的 Agent 可以对比 diff 精确定位问题；没有历史的 Agent 只能猜。

再往前一步，建议把仓库推到 GitHub。理由很实际：本地磁盘会坏，误删会发生，几十个小时的迭代成果不该只存在一台机器上。

一句话原则：所有代码项目都用 Git 管理，没有例外。项目再小也一样，因为「小项目」正是最容易被 AI 改崩且最没有备份的那一类。

3.3 AGENTS.md：写给 AI 的项目说明书

第二件事是创建AGENTS.md。你可以让 Agent 自己写这个文件：

创建一个 AGENTS.md 文件，写入下面这些内容，最后提交一个 commit。 （粘贴文件内容）

AGENTS.md的定位，相当于项目说明书 + 开发规范。Agent 每开启一轮新会话，会优先读取其中内容，从而快速建立项目背景和纪律约束。它解决的是 AI 编程里最讨厌的一个特性：会话是无记忆的。你在上一轮反复强调过的规则，新会话里它一概不知。把规则写进文件，等于把「口头叮嘱」升级成「常驻制度」。

最小可用的 AGENTS.md 其实只需要两条硬规则：

# 项目说明 本项目是一个极简电子书阅读器（项目名：马克阅读）。 # 开发规范（必须遵守） 1. 每次改动之后，必须创建一个对应的 git commit，以便后续追踪和回滚。 2. 每次改动之后，必须编写或更新相关测试；在交付给用户之前， 必须确保所有测试与自验收全部通过。

这两条为什么是「必须」？

第一条把版本管理变成 Agent 的肌肉记忆。每完成一个功能就顺手存一个快照，你不需要每次都提醒。后面哪一步改出了问题，能立刻找到最近一个正常版本退回去，不必担心代码越改越乱。

第二条把验证责任还给 Agent。默认情况下，Agent 写完代码就宣布完成，测试和试错成本全落在你身上——你打开应用、点点点、发现崩了、截图描述、它再改。这个循环极其昂贵。加上这条规则后，它会自己先跑一遍、测一遍，发现问题继续修，直到确认改动基本没问题才回来汇报。这一条能提前挡掉相当一部分显而易见的 bug，节省的是你最贵的资源：注意力。

创建完记得回去看一眼文件内容是否与预期一致。这个「口头汇报 + 人工抽查」的习惯，贯穿整个流程。

到这里环境就算搭好了。总结起来就两件事：Git 负责让错误可逆，AGENTS.md 负责让规则常驻。

四、第 2 步：产品设计——先讨论，再砍需求，最后落文档

环境搭好后，最容易犯的错误是立刻开始写代码。先停一下：你知道自己要做一个电子书阅读器，但「具体做成什么样」，大概还没有确切答案。

这个模糊状态是所有交付落差的源头。而它有个很好的解决办法：先跟 AI 讨论设计，不要让它写代码。

4.1 从一个开放式问题开始

第一条指令可以这样问：

我想做一个电子书阅读器，打算先从 MVP 版本开始。 你觉得这一版做哪些功能比较合适呢？

注意这里明确框定了MVP（Minimum Viable Product，最小可用产品）。含义是第一版只做最核心、最必要的功能，先把主流程跑通，其他慢慢加。

为什么必须从 MVP 起步？因为方向错误的成本是指数级的。一开始就把功能铺得很大，等到发现方向不对，大量工作直接作废——不只是代码，还有围绕这些代码写的测试、文档和架构决策。先用最低成本把最基本的体验做出来，确认没问题再往上加，是把风险控制在可承受范围内的唯一办法。

在 AI 编程里，MVP 还有一层额外价值：代码量越小，你越有能力审查它。一旦第一版就生成上万行代码，你实际上失去了对项目的控制权，只能听 AI 汇报。

4.2 关键动作：逐条砍掉「看起来很合理」的功能

AI 的第一版建议通常是「教科书式完整」的，而这恰恰是问题。以电子书阅读器为例，它给出的方案大致包含：导入本地 EPUB 文件、目录与章节导航、明亮/护眼/深色三主题、书签……

每一条都合理，合起来就不再是 MVP 了。这时候要做的不是接受，而是逐条追问「这个现在真的需要吗」：

• EPUB → TXT。EPUB 是常见电子书格式，支持它没错，但解析复杂度不低。既然是最小可用版本，起步功能越简单越好，先只支持最朴素的 TXT 文本文件。
• 去掉目录与章节。这是砍掉 EPUB 后的连带结论：纯文本文件本身没有目录和章节的概念，即使人工能看出章节划分，也没有稳定可靠的通用解析方法。强行做这个功能，等于在 MVP 阶段引入一个准确率不确定的启发式模块。
• 只留明亮主题。三套主题意味着三倍的样式维护和视觉验证成本，而它们对「能不能读书」这个核心价值毫无影响。先做明亮主题。
• 去掉书签。书签是「好用」功能，不是「可用」功能。它涉及持久化存储和状态管理，属于典型的可以延后项。

这里有个很实用的对话技巧：看完整个回答再一起提交意见。AI 的建议往往前后关联（砍掉 EPUB 会连带影响目录、章节、进度记忆），如果你看到一条就回一条，会陷入低效的多轮拉扯，而且容易前后矛盾。正确做法是把所有想法先追加到输入框里，最后一次性提交：

我觉得 EPUB 也稍微有些复杂了，一开始是不是可以只支持最简单的 TXT 文本文件？ 如果只做 TXT，那也就没有什么目录和章节可言了，毕竟 TXT 没有目录和章节的概念，这些也不用做。 只做明亮主题就行，护眼和深色可以先不做。 书签也可以先不做。 总之我们先做最基本的功能，其余功能后面再迭代。 你觉得前面这些想法有没有什么问题呢？

最后那句「你觉得有没有什么问题」很关键。它把 AI 从「执行者」切换回「评审者」，让它有机会指出你砍过头的地方。

4.3 让 AI 补齐你想不到的工程细节

这一轮回复通常最有价值。确认整体思路没问题之后，它会补上几个你大概不会主动想到的点：

• 文件编码：第一版仅支持 UTF-8。文本编码是中文场景的经典陷阱，GBK 文件不做处理就是一屏乱码。明确「只支持 UTF-8」既降低了实现复杂度，也定义了清晰的失败边界。
• 阅读方式：第一版只做纵向滚动，先不做分页。分页涉及文本测量、窗口尺寸响应、断行计算，是个隐藏的深坑；滚动几乎零成本。
• 大文件提示：载入大文件时需要给出加载提示。一个 20MB 的 TXT 一次性渲染会让界面直接卡死，而用户看到的只是「这软件坏了」。
• 延后功能清单：把砍掉的功能记录下来，作为后续迭代的输入。

这就是「先讨论再动手」的真正收益：你负责收窄范围，AI 负责补齐你的知识盲区。两者的信息优势是互补的——你知道自己想要什么，它知道这类产品通常会在哪里翻车。

讨论到这里，第一版的边界已经清楚了：

4.4 把共识落成产品设计文档

口头共识会在下一轮会话里蒸发，所以必须落成文档：

我同意你的建议。接下来帮我整理一份产品设计文档吧。 不用太详细，把整体方向和主要功能梳理出来就可以。

注意「不用太详细」这四个字。这不是偷懒，而是有意的权衡：

• 文档太长，你自己不会仔细读，等于没有评审；
• 过度细化的规格在第一版就会被现实推翻，写得越细，返工越多；
• MVP 阶段文档的核心职责是锁定范围，不是穷举实现细节。

只要大方向和你想的一致就可以推进。真有细节不符合预期，后面迭代成本很低。

这份文档接下来会成为整个项目的底稿：无论是做技术方案，还是让 AI 写代码，大家都有统一依据。它的实际作用是把「你脑子里的产品」变成一个外部化、可引用、可版本管理的对象——这也是为什么它应该和代码一起提交进 Git。

五、第 3 步：Demo——先把界面画出来

产品设计文档写完，还可以再加一个环节：让 AI 先做一个可操作的 demo。

5.1 什么是 demo

这里说的 demo，是一个只有前端、没有后端的可交互页面。

先明确两个词：前端指你看得见、点得到的界面；后端指背后真正处理数据、执行功能的逻辑。做 demo 时通常只把前端做出来，后端暂时不实现，页面里的数据全部是模拟的。

举个具体例子。一个「个人知识库」的 demo，实际就是一个单独的 HTML 文件，双击就能打开：左边是文档列表，中间给出一些推荐问题，点击某个问题它开始「回答」，回答完点击引用文件，右边展示引用的原文段落。

看起来功能齐全，但只有界面是真的——回答内容和知识库文件全部是写死的假数据，因为后端逻辑压根还没实现。它唯一的目的，是让你亲手体验一遍界面交互和操作流程到底顺不顺手。哪里感觉不对，就继续让 AI 改这个 demo，直到整体体验符合预期。

5.2 demo 解决两个真问题

第一，提前验证产品设计。很多东西光靠文字实在难以想象。文档里写「导入文件后进入阅读界面」，你脑子里那一幕是清晰的，但真把页面画出来、亲手点一遍，你可能立刻发现：导入按钮该放哪？导入失败怎么提示？字号调节要不要常驻在界面上？这些问题在纯文字阶段几乎不会浮现，在 demo 上五分钟就能全部暴露。发现设计不合理，就改 demo，同时把产品设计文档一起同步调整——两者必须保持一致，否则后面 AI 会在两份冲突的依据之间随机选一个。

第二，让后续实现更精确。demo 能非常直观地告诉 AI「我最终想要的产品大概就是这个样子」，而这是文字描述极难做到的。真正实现时，把产品设计文档和 demo 一起交给 AI：文档说明做哪些功能，demo 说明界面和交互长什么样。两个维度的约束叠加，做出来的东西会明显更接近预期。

本质上，demo 是一种低成本的规格表达。界面这类信息，用图形表达的保真度远高于自然语言；同一段文字描述可以对应几十种界面实现，而一个 demo 只对应一种。

5.3 什么时候值得做 demo

demo 不是必需环节。判断标准可以非常简单：看这个产品的后端实现成本有多高。

• 后端成本高 → 强烈建议做 demo。像个人知识库这类产品，后端涉及文档处理、检索策略、模型调用等一大堆逻辑，实现周期长、返工代价大。这种情况下，先用几乎零成本的前端把设计验证一遍，再投入后端，性价比极高。
• 后端成本低 → 可以直接开工。如果后端逻辑很轻，做 demo 和做真东西的成本差不多，那 demo 就成了纯粹的重复劳动，直接实现再调整反而更快。

这个判断的底层逻辑是：demo 的价值等于它避免的返工成本，减去它自身的制作成本。后端越重，前者越大；后端越轻，两者越接近甚至倒挂。

六、第 4 步：从设计到实现——技术方案与任务拆解

设计和 demo 确认后，才轮到写代码。这里同样不建议一步到位，而是再插入两个轻量环节。

6.1 技术方案：把「怎么做」也先说清楚

产品设计文档回答的是「做什么」，技术方案回答的是「怎么做」：技术栈选型、数据如何存储、模块如何划分、目录结构长什么样。

可以让 AI 基于已有文档先给方案，你只审几个关键判断：

• 技术栈是否过重。一个本地 TXT 阅读器不需要引入完整的前后端分离架构和数据库。
• 依赖是否必要。每一个第三方依赖都是未来的维护负担和安全面。
• 模块边界是否清晰。文件读取、文本渲染、设置管理应当分离，否则后面加 EPUB 支持时会牵一发动全身。

审技术方案的收益比审代码高得多：一个架构决策错误会污染成百上千行代码，而在方案阶段改掉它只需要改一段文字。

6.2 任务拆解：不要让 AI 一次做完所有事

把 MVP 拆成一串可以独立验证的小任务，每个任务对应一个 commit。以马克阅读为例：

1. 搭起最小可运行骨架，界面能打开
2. 支持选择并导入本地 TXT（仅 UTF-8）
3. 文本纵向滚动渲染，字号可调
4. 大文件加载提示与异常处理
5. 明亮主题的样式打磨

分段实现的收益是可叠加的：

• 每一步都可验证。你在每个节点都能确认「这一段确实是我想要的」，问题在产生时就被发现，而不是在一堆代码里考古。
• 每一步都可回滚。第 4 步改崩了，回到第 3 步的 commit，前面的成果毫发无损。
• 上下文压力更小。一次只处理一个任务，Agent 的注意力不会被十个并行目标稀释——这是 AI 编程质量的关键变量之一。

对应的指令风格也很直接：

请严格按照产品设计文档和 demo 的界面，实现第 2 个任务： 支持选择并导入本地 TXT 文件（仅 UTF-8）。 不要顺手实现其他任务里的功能。完成后按 AGENTS.md 的规范补充测试并提交 commit。

最后那句「不要顺手实现其他功能」值得每次都写。Agent 有很强的「顺手多做一点」倾向，而超出范围的改动是你最难审查、也最容易埋雷的部分。

七、第 5 步：验收与迭代

7.1 验收要自己动手

即使 AGENTS.md 已经要求 Agent 自测，你仍然需要亲自验一遍。原因很简单：Agent 能验证代码是否符合它自己的理解，无法验证它的理解是否符合你的预期。测试全绿和产品可用之间，永远存在一段只有人能跨过的距离。

验收时重点看三类东西：

发现问题时，描述现象而不是猜测原因：「导入 15MB 的 TXT 后界面白屏约 10 秒，没有任何提示」远好于「你的渲染逻辑有性能问题」。前者是可靠的观测事实，后者是可能误导 Agent 的假设。

7.2 迭代：把砍掉的功能一个个加回来

MVP 跑通之后，前面延后的功能清单就是天然的迭代路线图：EPUB 支持、目录与章节、深色与护眼主题、书签、阅读进度记忆……

迭代的纪律和第一版完全一致，只是节奏更快：

1. 更新产品设计文档（新增功能的边界）
2. 必要时更新 demo（界面有明显变化时）
3. 拆解任务、分段实现
4. 自己验收、提交 commit

值得强调的是：文档必须跟着代码一起演进。一份和代码脱节的设计文档，比没有文档更危险——它会持续给 AI 提供过时的依据，让它在错误的前提上做出看似合理的决策。

八、哪些环节可以省，哪些千万别省

这套流程不是教条，可以按项目规模裁剪。我的判断标准如下：

可以看到，能省的都是「表达形式」，不能省的都是「控制机制」。文档可以写薄，demo 可以不做，但版本可回滚、范围有边界、结果有人验，这三件事没有妥协空间。

九、几个常见的坑

一次性提出全部需求。把十个功能一口气丢给 AI，它会全部实现，也会全部实现得很浅，而且你无法定位是哪一部分出了问题。

让 AI 修复它自己搞乱的代码。当同一个 bug 修了三轮还没好，正确动作是git reset回到干净版本，换一种思路重新描述需求，而不是继续在废墟上叠补丁。

只看汇报不看结果。Agent 说「已完成并通过所有测试」时，去看文件、去跑一遍。抽查成本很低，被误导的成本很高。

文档写得比代码还细。MVP 阶段的文档只需要锁定范围。过早细化的规格几乎必然被现实推翻。

跳过 MVP 直接做完整版。这是所有坑里最贵的一个：它把方向验证推迟到了投入最大的时刻。

十、结语：流程才是真正的能力

回过头看，这套流程做的其实只有一件事：把不确定性从「实现阶段」前移到「设计阶段」。

设计阶段的错误，改一段文字就行；实现阶段的错误，要改一堆代码；上线之后的错误，要改用户的习惯。AI 让写代码的成本急剧下降，但它同时放大了方向错误的代价——因为错误的方向现在也能被高效地执行出上万行代码。

所以真正的分水岭不在于谁的提示词更花哨，而在于谁能把「我想要什么」表达得足够清楚、把「什么叫做完了」定义得足够明确、把「出错了怎么退回去」准备得足够充分。

把这三件事做好，剩下的交给 AI，它大概率能给你一个满意的答案。

最后再回到最小可行的那一版实践建议：从今天开始，给你的每个项目做三件事——初始化 Git、写一份十行的 AGENTS.md、在动手前先跟 AI 聊清楚第一版的边界。这三件事加起来不超过十五分钟，但它们能改变你和 AI 协作的全部质量基线。