企业官网建设流程全解析

接了个小需求：用户上传图片后自动加个水印，再在网页上展示。按以前的玩法，我得写接口、调图片处理库、安排存储、再部署，两三天能上线算顺利。这次全程让 AI 辅助，最后一天半搞定。真正难的其实不是让 AI 写代码，而是把脑子里那堆“口水需求”翻译成它能执行的任务。你直接说“帮我写个图片上传”，它确实会甩给你一堆代码，但离生产部署差了十万八千里。折腾几轮后，我把整个流程压缩成 5 个「咒语」模板，分别对应需求澄清、方案设计、代码生成、调试排错、生产部署。下面直接摊开讲，模板全文、使用场景、踩过的坑都写上。

1. 为什么普通提示词总翻车：从“口水需求”到“可执行指令”的鸿沟

“帮我做个登录”“写个文件上传”“做一张后台截图”——这些话本质上是需求垃圾，里面藏着大量未确定的维度：用什么框架？有什么权限模型？数据存哪里？失败怎么处理？AI 为了迎合你，会在默认假设下填空，然后把一个想当然的结果塞给你。所以你会觉得它“答非所问”。其实它并没有多聪明，只是在用概率填空；你提供的信息越少，它填得越离谱。用模板的本质，就是把传统研发流程里的“阶段性审查”翻译成对 AI 的指令控制。

1.1 你经历的“AI答非所问”现场

举个最小例子。向 AI 说“给我写个文件上传功能”，它多半会给你一段 Express + multer 的代码，也可能给出 Python Flask 的版本。但你的服务器可能是 Node，也可能是 Java；前端可能是 Vue，也可能原生 HTML；存储可能是本地磁盘，也可能对象存储。任何一个变量没提，AI 就会随机挑一套，然后你就开始和它打拉锯战：改框架、改存储、改接口，每一轮都在浪费对话窗口和你的耐心。更可怕的是，如果第一版代码已经绑定了一套结构，后面让它改，它可能会改得支离破碎。

1.2 五个模板的底层逻辑

我最后使用的五个模板，本质上是在模拟一个成熟研发流程的五个门禁：需求门禁（想清楚做什么）、方案门禁（决定怎么做）、实现门禁（按契约编码）、调试门禁（用证据排查）、上线门禁（生产环境自检）。这个流程不新鲜，但直接对 AI 说“按流程走”它并不会照做，必须用具体的指令格式，也就是咒语，把每个阶段的目标、边界、输出格式都钉死。所以每个模板里都会包含四要素：角色、任务、约束、输出格式。这四要素缺一个，输出质量就会断崖式下跌。

2. 咒语一：需求澄清——把“我想要个功能”变成“需求说明书”

这个阶段最容易被人跳过。我见过很多人把需求丢给 AI 后就直接说“写代码”，结果代码没写几行，需求变了好几次。原因很简单：你对需求的理解是上下文，AI 没有这个上下文。与其等它瞎猜，不如先用一个回合把模糊点全揪出来。

2.1 模板原文与适用场景

当你的脑海里只有一个“大概功能”时，用这个模板：

你是一名资深产品经理。请针对下面的原始需求，向我提出10个必须回答的澄清问题。每个问题后面附上“为什么关心这个问题”，方便我理解你的意图。不要开始写代码，只做需求澄清。 原始需求： <粘贴你的口水需求>

适用场景包括：想法还不成型、老板只给一句话、需求文档只有标题的情况。注意，不要在这一步给 AI 太多技术细节，因为产品经理角色更关注业务边界，技术细节留给下一轮。但如果你已经确定技术栈，可以在末尾加一句“不考虑技术实现，只问业务问题”。

2.2 拆解模板里的三个关键指令

第一个关键指令是“10个问题”。如果不限定数量，AI 可能只问三五个，也可能列出二十个，都很浪费。通常 10 个足够覆盖业务、权限、异常、性能四类。第二个关键指令是“为什么关心这个问题”。这一点极容易被忽略：AI 问了问题后，你往往不知道这个问题重不重要。加上这句之后，它会解释，这样你在回答时会意识到自己的选择会带来什么后果。第三个关键指令是“不要开始写代码”。这句话能挡住绝大多数不请自来的实现方案。

我自己的经验是：收到问题后，不要老老实实一次全答完，挑那些真正没想清楚的回答，剩下的可以写“暂定，按默认处理”。这样能让后续的方案设计有重心。

2.3 一次真实对话记录（简化）

原始需求是：“做一个图片上传功能，能给图片加水印，然后展示出来。”

AI 问的前三个问题：

1. 上传图片的格式和大小限制是多少？为什么关心：决定存储成本和上传组件的选型。
2. 水印是文字还是图片Logo？位置固定还是可调？为什么关心：影响图片处理库的选择与处理耗时。
3. 图片是公开访问还是登录后可见？为什么关心：决定权限模型和接口设计。

我回答：格式 JPG/PNG，大小不超过5MB；水印用文字（如“某内容平台”）；图片登录后可见。

这四个信息出来之后，“需求说明书”的骨架已经在了。把它粘贴到下一个模板里时，AI 给的方案明显收敛。

3. 咒语二：方案设计——让 AI 先画图纸再动手

需求说明书出来之后，很多人急着写代码。我建议多花几分钟让 AI 给一份方案，先画图纸再动手，能少走很多弯路。

3.1 模板原文与适用场景

你是一位实战经验丰富的后端工程师。请基于以下需求，给出一个最小可行的技术方案，包括模块划分、核心数据模型、接口设计、关键技术选型和风险点。要求： 1. 不过度设计，放弃当前用不到的能力； 2. 明确技术栈：<你的技术栈>； 3. 给出至少3个需要重点关注的异常场景； 4. 用Markdown表格输出需求、模块、接口之间的关系。 需求： <粘贴需求说明书>

适用场景：需求已经清楚了，但还没开始实现；或者当你拿不准“怎么做最省事”时。哪怕你心里已经有了方案，也让 AI 先输出一版，再对照你的预期，往往能发现遗漏。

3.2 为什么“最小可行方案”这么重要

AI 在生成方案时倾向于把常见的进阶设计也加进去，比如用户多了需要缓存、文件多了需要分布式存储。如果不告诉它“最小可行”，它就会把这些默认带上，导致你写了个简单功能却要维护一堆复杂依赖。加上“最小可行”后，AI 才会意识到它只需要一个同步接口、一张数据表、一个加工流程。比如我的需求，方案里最初给了“上传后异步处理队列”，我要求砍掉，最后改成同步函数，处理时间从 800ms 降到 300ms。这就是最小化方案的收益。

3.3 如何追问设计细节

如果方案里有你不确定的点，可以继续用咒语追问：

针对方案中的“对象存储vs本地存储”，请用表格对比它们的成本、部署复杂度、备份难度，假设日均上传1000张图、每张1MB，并给出当前阶段的建议。

这里的关键是：让 AI 用“场景化数据”做决策，而不是泛泛而谈。当它看到具体数字时，会给出更诚实的判断，比如“日均1000张图优先本地存储，一年约365GB，用额外磁盘足够”。追问两三轮之后，设计方案会变得很扎实。

4. 咒语三：代码生成——按接口契约输出，别让它放飞自我

设计方案没有争议后，就到了最爽也最容易翻车的环节。直接说“按方案实现一下”，AI 可能会生成整个工程，还会私自加功能。所以要用模板控制。

4.1 模板原文与适用场景

请按照以下设计要求，实现核心函数/模块。 设计要求：<粘贴设计方案> 接口签名（必须遵守）： - def upload_image(file: bytes, user_id: str) -> str - def add_watermark(image: bytes, watermark: str) -> bytes 要求： 1. 只输出核心代码，不要完整工程； 2. 处理输入为空、文件过大、水印字符过长等异常； 3. 添加关键逻辑的注释； 4. 先给出实现思路，再写代码。

适用场景：要生成具体函数、模块、服务或数据处理流程时。如果你需要完整代码，可以把“不要完整工程”改成“生成仓库结构，但重点文件列出”，不过新手阶段越聚焦越好。

4.2 控制输出范围的三个技巧

第一个技巧是写死“接口签名”。拿我的项目来说，如果不写签名，AI 会自己发明一个upload_image(file_path, text)，可能把文件路径和字节流混在一起。写死签名后，输出结果能被你的调用方或前端直接对接。第二个技巧是“只输出核心代码”。这能防止它给出杂七杂八的配置文件、测试文件、Dockerfile，让代码量控制在可审视线内。第三个技巧是“先给出实现思路，再写代码”。这一步很有用，因为你能在动手改之前先判断思路对不对；如果思路不对，你直接说“思路换掉”，不用先骂完代码再重来。

实际生成时，AI 可能会给出类似if not image: raise ValueError("image is empty")这样的保护。如果你忘了让它处理异常，它就可能直接访问空对象。这也是模板里强制要求异常处理的原因。

4.3 生成代码的审查清单

代码生成后需要逐项检查：

拿第一版代码来说，AI 在加水印函数里用了 Pillow，这是合理的；但它还顺手import requests，明显没用。删掉后镜像还能小一圈。记住：AI 生成的是“可能性”，不是“正确性”，审查永远不能省。

5. 咒语四：调试排错——把错误喂回去，让AI当debug搭档

代码一旦运行报错，很多人会慌。别急，第四咒语专门对付报错，核心思路是把错误上下文完整喂回去。

5.1 模板原文与适用场景

运行环境：<Python 3.12 / Node 22 / 其他> 完整报错信息： <粘贴报错堆栈> 我正在执行的操作： <描述触发步骤> 请帮我： 1. 列出可能导致这个错误的原因，按可能性从高到低排列； 2. 给出每个原因的验证方法； 3. 不要直接重写代码，先告诉我改哪一行、为什么改； 4. 如果涉及依赖冲突，给出具体的依赖版本。

适用场景：程序启动失败、接口返回 500、页面显示不正常、报错堆栈看不懂等。注意：一定要把“完整报错信息”贴上去，别只贴“运行不了”。

5.2 调试时的“上下文注入”策略

AI 排查问题最大的障碍不是逻辑弱，而是信息不足。它不知道你的调用方式，也不知道你改了哪行。我的做法是“三段式注入”：报错堆栈、相关函数签名、最近改动的地方。如果错误发生在第三方库，还要加上你调用它的那几行。这三个信息组合起来，AI 通常能定位到根因。有一次，我上传图片后网页一直转圈，控制台报了一个加载资源 404。我把这个信息连同路由代码发给 AI，它很快就指出“前端图片 URL 拼错了，少加一个路径前缀”。这个 bug 如果自己查，得在浏览器 Network 面板里看半天，但 AI 几秒钟就从路径逻辑里找到了问题。

5.3 让AI别乱改代码的防呆写法

模板里那句“不要直接重写代码，先告诉我改哪一行、为什么改”，对 AI 有很强的约束力。如果你的模型喜欢热心重写，一定要保留这句。另外，如果 AI 连续两次给出的原因不一样，说明上下文可能不足。这时不要急着追问，我建议你让它给一段临时日志代码，你运行后把日志粘回来，再继续用模板排查。往往一轮日志就能锁定问题。

6. 咒语五：生产部署——上线前最后一关的审查清单

代码在本地跑通只是第一步，生产环境有太多坑：端口冲突、权限不对、容器内缺依赖、内存爆掉。第五咒语用来让 AI 做“部署前审查”。

6.1 模板原文与适用场景

请以DevOps工程师身份，审查以下部署方案/配置/代码，给出可能在生产环境出问题的地方。 部署环境：<Linux + Docker + Nginx> 项目简介：<一句话> 部署方案/关键代码： <粘贴> 输出内容： 1. 必须修复的安全问题（按严重程度排序）； 2. 可能引起内存/磁盘/CPU问题的配置； 3. 日志与监控的遗漏； 4. 建议的Dockerfile优化； 5. 用Checklist表格输出，每条包含“风险级别”“建议操作”。

适用场景：准备上线、写 Dockerfile、配 Nginx、调 CI/CD 之前。哪怕你的部署配置只有几行，也能让它审查。

6.2 安全与配置必须人工确认的5项

AI 审查完之后，还要自己过的 5 项安全关卡：

• 密钥管理：代码或配置文件里不能出现明文密码、Token，要用环境变量引用。
• 数据面暴露：数据库端口不能映射到公网，调试接口不能在生产开启。
• 容器用户：Dockerfile 里是否显式创建了低权限用户，而不是默认 root 运行。
• 资源限制：上传功能是否有client_max_body_size、容器内存上限等限制。
• 备份与回滚：数据库是否定期备份，镜像版本是否保留可回滚的 tag。

很多时候 AI 会忽略这些，因为需求里没写，所以你要主动加进模板里。我的经验是，只要在模板最后补一句“重点检查上传类接口与文件存储的安全性”，AI 就会给出更具体的建议，比如“需要校验文件头，防止伪装图片”。

6.3 从Docker到CI/CD的最简落地

如果你的项目已经能在本地跑通，先把容器化落地，再做自动化。AI 可以帮你生成一个初版 Dockerfile：

FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . RUN useradd appuser USER appuser EXPOSE 8000 CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

但别直接拿去生产。我见过它生成的 Dockerfile 里没有--no-cache-dir，也没有USER appuser，导致镜像体积大且以 root 运行。你可以把这段 Dockerfile 丢进第五咒语里审查，AI 会告诉你：缺少依赖锁文件、缺少健康检查、缺少时区设置等。把这些建议落实后，Docker 镜像才敢部署。CI/CD 则等部署过一次成功后再接入，否则自动化只会更快地生产故障。

7. 高频翻车现场与我的补救套路

再好的模板也防不住所有的坑。我把实际遇到的问题整理成速查表，方便你直接对号入座。

7.1 失败模式速查表

7.2 我的通用兜底流程

当某个功能的 AI 辅助过程超过五轮还没有收敛，我通常会直接“重启”。新建一个对话，把当前已经确认的需求、方案、报错原文都粘进去，再用一个“总咒语”开场：

请按以下顺序处理我的需求： 1. 如果需求不清晰，先提问； 2. 给出最小方案； 3. 实现指定核心函数； 4. 最后做部署审查。 当前需求是：<需求> 已明确的约束：<约束>

这个做法往往比我继续追问旧对话有效，因为之前对话里已经堆了大量错误假设，AI 的偏好被带偏了。重置后，它能基于干净上下文重新生成更准确的答案。我还发现，模型虽然不同，但模板的生命力在于“把抽象目标翻译成具体动作”，所以换模型时模板几乎不用改。

8. 最后再分享一点自己的习惯

五个模板不是复制即万能的银弹，也不能保证 AI 一次写出毫无 bug 的代码。但它们确实改变了我跟 AI 协作的方式。

8.1 这套模板给我带来的最大变化

我花在和 AI 讨价还价上的时间变少了，真正花在“想清楚需求”上的时间变多了。这看起来是绕了远路，实际上却少走了很多弯路。以前拿到需求就开干，一半时间在返工；现在先花十分钟让 AI 提问、给方案，后面基本是顺着路子往下走。尤其是需求澄清和方案设计这两个步骤，几乎能消灭一半的无用功。

8.2 如果你现在就想开始试

我的建议是先拿一个不超过两天的小功能，完整走一遍这五个阶段，体会一下“需求澄清-方案设计-代码生成-调试-部署”的节奏。第一遍可以把模板原样抄走，但一定不要无脑复制。跑完一个完整流程后，你自然会知道哪些位置需要加细节，哪些约束对你手头的模型更有效。走通一次之后，这些咒语就不再是模板，而是你自己的工具。祝顺利。