企业官网建设流程全解析

最近好几个朋友都来问我，说 WorkBuddy 装上之后感觉就是个高级聊天框，写规则、写提示词总差那么点意思，问出来的代码时好时坏。这其实是卡在了提示词工程上，WorkBuddy 这类 AI 编程工作台，底层能力再强，你给它的指令模糊，它就只能给你模糊的反馈。我把自己用了大半年 WorkBuddy 的提示词整理了一下，筛出 5 条真正派得上用场的，都是直接复制就能跑的模板，附带使用上下文、参数含义和避坑点，看完可以直接贴进你的工作台里。

我最早接触 WorkBuddy 是被它那个 Skill 机制吸引来的，后来实际写项目才发现，真正的分水岭不在工具本身，而在于你怎么把大脑里的意图翻译成它听得懂的指令。这件事说白了就是提示词工程，但又不是简单地“请你帮我写个登录功能”这种对话，而是要把上下文、约束、输出格式、验收标准全都拧在一起。鹈鹕骑自行车那个测试你大概听说过，就是给 AI 一个充满矛盾的指令看它能不能识别出来——本质上就是在考验模型对约束条件的敏感度。实际写提示词的时候，这种约束意识特别重要，你少写一个“不要改数据库表结构”，它就可能顺手给你重构了。

这 5 条提示词都是我在真实项目里打磨过的，覆盖全局规则、代码审查、重构、测试用例、Skill 编排五个高频场景。每一条我都会把为什么这么写、关键参数怎么调、遇到什么情况要改哪里说清楚。有几条还踩过挺深的坑，比如规则被后续对话覆盖、上下文被撑爆、输出格式不稳定，这些我都会把当时的排查思路写出来。

1. WorkBuddy 提示词的底层逻辑：先看懂它怎么“想”

1.1 WorkBuddy 不是搜索引擎，它是你的结对程序员

WorkBuddy 这类 AI 编程助手和搜索引擎最大的区别在于，它没有记忆库，它所有判断只基于当前对话窗口里的上下文。你把多少信息喂进去，它就站在多高的起点上工作。你上来丢一句“帮我优化一下代码”，它不知道你代码在哪、优化目标是性能还是可读性、有没有兼容老接口的约束，自然只能给你一个“看起来正确但未必好用”的结果。

所以提示词的本质，是把你的隐性经验显性化——你脑子里的项目背景、技术选型原因、历史踩坑记录，都得通过文字告诉它。这也是为什么同样一套 WorkBuddy，有人用起来像资深架构师，有人用起来像刚毕业的实习生，差别不在模型版本，在上下文喂得够不够。

我在一次重构支付模块的时候，光是把“支付状态机不能破坏现有的回调幂等逻辑”“数据库表结构不允许变更”“对外接口签名不能动”这三条约束写进提示词，生成的代码就直接能跑，连自我修正的来回都省了。反观有一次没写约束让它自由发挥，它给我把整套接口都改了，前端同事追了我一整天。从那以后，我写提示词必带三样东西：项目背景、技术约束、产出格式。

1.2 提示词六要素：角色、任务、上下文、约束、格式、验收

我在实战中总结了一套六要素写法，覆盖了普通用户和高级用户之间的差距：

角色（Role）解决的是“站在什么视角干活”，比如资深后端工程师、安全审计专家、测试架构师，这决定了模型输出的专业侧重。任务（Task）要具体到动词级别，比如“找出这段代码的并发隐患”而不是“看看这段代码”。上下文（Context）提供项目背景、相关文件路径、决策记录，这决定模型的起点高度。约束（Constraints）是红线，规定不许干什么，比如不允许改接口签名、不允许引入新依赖，这条最少写 3 个，否则模型很容易跑偏。格式（Format）指定输出的样子，比如 Markdown 表格、按严重程度分级的报告，这直接决定你能不能把它当作可执行的工作产物。验收（Acceptance）是最后一道关卡，告诉它怎样算干完，没有验收标准的提示词容易让模型在一个点上无限发散。

鹈鹕骑自行车那个经典测试其实就是个化简版提示词实验：如果指令里存在物理世界的矛盾，模型能否判断约束不可满足并主动纠偏。你在 WorkBuddy 里写提示词也要有这个意识——如果给了一个不可能同时满足的约束组合，它可能会自顾自选一条路径执行，而不是来反问。所以每次写长提示词之前，我都会默读一遍，检查有没有自相矛盾的条款。

1.3 上下文工程：比提示词本身更值得花时间的东西

WorkBuddy 里有个概念很关键——上下文长度是有限资源。你给它 20 万 token 的窗口，不代表你可以塞 20 万 token 的废话进去。塞进去的代码如果是过时的、无关的、损坏的，反而会稀释它对当前任务的关注度。这就是“上下文污染”问题。

我常用的策略是“最小相关上下文”：前提是我告诉它文件路径和函数名，让它自己决定要不要读文件，而不是把整个文件内容复制进去。对于大型项目，我更倾向于给它一个“地图式”介绍：项目结构、核心模块、本次任务涉及的文件路径，然后让它按需读取。这样既节省 token，又不会让它被无关代码干扰判断。有一段时间我图省事，把整个项目打包塞进去，结果生成的代码频繁引用不存在的模块，排查了半天才意识到是上下文里混进了旧版代码。

所以你在 WorkBuddy 里搭工作台，第一件事不是写花哨的提示词，而是建立一套上下文管理习惯：哪些信息固定给、哪些信息按需给、哪些信息永远不给。规则和提示词只是上层建筑，底层是这条上下文管理的护城河。

2. 第一条可直接用的提示词：设定全局规则，让约束对后续所有任务生效

2.1 全局规则提示词模板

很多用户不知道 WorkBuddy 有一个“全局指令”或者“项目规则”机制，可以把它想象成一个常驻记忆区，你在这里写下的规则，后续所有对话都会默认带上。这就相当于你给新同事的第一天培训——告诉他项目规矩、代码风格、禁忌清单，后续他干活就有章可循。

我给自己常用的一个全局规则模板如下，你可以直接复制进 WorkBuddy 的设置项里：

你是本项目的高级技术顾问，说话直接但专业。在处理我后续所有任务时，默认遵守以下硬性规则： 1. 不修改数据库表结构和已有接口签名，除非我明确要求。 2. 代码改动必须保持原有代码风格，缩进、命名、括号风格不做无谓调整。 3. 在给出代码之前，先用两句话说明你的修改思路，帮助我快速判断方向是否正确。 4. 引入新的第三方依赖之前，必须列出依赖名称、用途、体积预估，等我确认后才可以动工。 5. 任何删除代码的操作都必须先展示被删除内容，说明删除理由。 6. 回答一律使用中文，代码注释用中文。 7. 如果发现我的需求和已有规则矛盾，直接指出来，不要默默选择一个方向执行。

这条规则的价值在于两个地方：第一，它把“人跟人合作时默认存在的东西”显性化了，模型没有人类社会那种“不言自明”的默契，一切都要落在字面上；第二，第 7 条特别关键，它允许模型在遇到矛盾时主动纠偏，而不是闷头执行。

2.2 为什么全局规则能救命：一次被重构的惨痛经历

我印象特别深的一次是接手一个老项目，技术栈还是 jQuery，我让 WorkBuddy 改一个弹窗组件的样式，结果它自作主张把弹窗初始化方式改成了现代 ES Module 写法，还引入了一个新工具库。全局没有约束的前提下，它做的每一步从局部看都“合理”，但合在一起就是把老项目往新架构上生拉硬拽，最后整个页面都白屏了。

加了全局规则之后，同样的问题再没出现过，尤其是第 3 条，让它在动代码之前先讲思路，我一看方向不对能立刻喊停。这个习惯成本极低，但能省掉大把返工时间。我还特意把第 4 条写进去，因为 AI 特别爱推新依赖，有时候一个 5 行的函数它都要推荐装个 lodash，有了这条它就会收敛一点。

注意：全局规则不是越多越好，超过 10 条反而会让模型抓不住重点。保持 5 到 8 条，聚焦在“红线”级别的事项上，日常的代码风格问题用第 2 条兜底就够了。

2.3 适配建议：根据项目特性微调规则

不同技术栈的团队，全局规则侧重点完全不一样。做微服务项目的团队，应该在规则里加上“不允许随意在服务之间增加同步调用”“遵循现有的分布式链路规范”；做前端组件库的团队，要加“所有组件导出必须有类型定义”“保持 API 向后兼容”；做算法项目的团队，要加“所有涉及随机数的代码必须设置随机种子，保证可复现”。

这套规则之所以能“对后续所有任务生效”，原理就是每次对话开始时，WorkBuddy 把全局指令像座右铭一样贴在上下文的顶部。模型在生成第一个词之前就已经“看过”了这些规则，所以后续所有代码都受它约束。它不是玄学，是实打实的上下文工程优化。

3. 第二条可直接用的提示词：代码审查与隐患扫描

3.1 代码审查提示词模板

我在提交代码之前习惯让 WorkBuddy 先做一轮“虚拟 Code Review”。不是让它泛泛地夸几句“代码写得很清晰”，而是指定它扮演一个挑剔的审查者，按照我定的维度去找茬。模板如下：

请以资深代码审查专家的身份，对以下代码进行严格审查。 文件路径：{project_root}/src/utils/dateFormatter.ts 审查维度： 1. 边界条件：日期范围、时区、闰年、非法输入。 2. 性能隐患：循环内是否有重复计算、是否有不必要的对象创建。 3. 并发安全：是否有共享可变状态。 4. 错误处理：catch 后是否吞异常、是否暴露内部错误细节。 5. 可维护性：命名是否清晰、函数是否过长、职责是否单一。 输出格式要求： - 按严重程度分级：严重（会导致线上故障）、中等（可能引发问题）、建议（代码整洁度层面）。 - 每个问题附带行号（如果可以看到行号则标注）、问题类型、修改建议。 - 最后给出一个总的结论：是否可以合入主干分支。 代码内容如下： {这里放入代码，避免让它自己去翻文件，审查场景下上下文完整性优先}

这个模板的核心在于“审查维度”这一段，你不给维度，它只会泛泛而谈；给了维度，它就变成了一个带检查清单的审计员。实测下来，边界条件和性能隐患这两个维度收获最大，它经常能发现我压根没考虑到的时区和闰年问题。

3.2 审查类提示词的关键参数：严重程度分级与续审机制

严重程度分级这个设计特别重要。第一次用的时候它可能一口气列 20 个问题，你要挨个判断优先级，反而比不审查还累。分级之后，我可以直接跳到“严重”一栏看，没有严重问题就放心合入，中等和建议级别的留给后续迭代再说。我实际操作时还有一个技巧：让它最后一轮只输出严重级别以上的问题。就是我先把第一轮审查报告留着，然后追加一句“忽略建议级别问题，重新整理一份中等及以上问题的清单”，这样最终交付只剩一页纸，效率更高。

提示：审查类任务最忌讳一次塞太多代码。我建议单次审查控制在 300 行以内，多了模型容易漏检，而且输出质量会明显下降。每次审查一个文件或一个大函数，才是正确用法。

还有一点值得注意：让模型审查自己生成的代码，效果会打折扣。它有路径依赖，自己造的代码自己很难挑刺。我更推荐一种“交叉审查”的玩法——让 WorkBuddy 生成代码，然后把你期望的约束用一个完全不同的提示词模板（比如让一个扮演“QA 工程师”的角色再审一遍）检查，角色切换能有效打破思维惯性。

3.3 实测案例：定位到一个隐藏时区 Bug

有次我写了一个日期组件，内部用new Date()直接处理用户输入的日期字符串，自己测试没发现问题。交给 WorkBuddy 审查后，它直接指出：如果用户所在时区是西半球，new Date('2024-01-01')会被解析为 UTC 零点，而本地显示可能落到前一天，这在国际化项目里就是实打实的线上 bug。它给出的修改方案是，用new Date(year, month-1, day)这种本地时间构造方式替代字符串解析。这个案例让我对“给足维度的审查提示词”彻底服气，因为它实际上是在用工程经验帮你兜底，而不是单纯把代码重写一遍。

4. 第三条可直接用的提示词：目标导向重构，不改变行为

4.1 重构提示词模板

重构和改功能是两回事。改功能你需要描述“新行为是什么”，重构你需要强调“行为不变，内部变”。WorkBuddy 在这两种任务里需要的信息完全不同。我做重构时的标准提示词是这样的：

你是一名资深前端架构师，现在要对下面的代码做一次不影响外部行为的结构性重构。 重构目标：把目前散落在多个函数中的日期格式化逻辑提取到统一的 utils/date.ts 中，并消除重复代码。 硬性约束： - 函数签名保持完全不变，包括参数名、参数数量、返回类型。 - 不改变任何现有测试用例的预期结果。 - 不引入新的第三方依赖。 - 不修改调用了这些函数的外部文件。 步骤要求： 1. 先分析当前代码的运行流程，用 100 字以内概述。 2. 给出重构后的代码，附上关键改动点的注释。 3. 列出哪些行为保持了不变、哪些内部实现变了。 4. 如果重构过程中识别到潜在 bug，单独分一个“顺带发现的问题”小节说明，不要混在重构代码里。 当前代码： {代码放在这里，或者提供文件路径，但建议直接粘贴以保证上下文完整性}

这个提示词里有几个细节是反复打磨过的。第一是“步骤要求”，强制它先概述再改代码，避免它一上来就哗啦啦输出一坨重构结果，你根本没法判断它思路对不对。第二是“顺带发现的问题”单独成节，因为重构过程中它必然会观察到一些原本的坏味道或潜在 bug，如果不单独约束，它会忍不住直接改掉，导致重构范围失控。

4.2 重构任务最容易翻车的两个点：范围蔓延与行为漂移

重构任务里最常见的问题就是范围蔓延——你说要提取重复逻辑，它顺手把命名风格改了、把函数拆得更细、甚至重排了文件目录结构。有了硬性约束第一条“函数签名完全不变”和第三条“不引入新依赖”，范围蔓延基本被拦死。第二个常见问题是行为漂移，重构后代码看着更漂亮了，但某些边界行为变了，比如原来允许传入null值，重构后直接抛异常；原来NaN返回空字符串，重构后返回'NaN'。这种行为漂移在单元测试覆盖不全的项目里几乎发现不了，等上线炸了才追悔莫及。

所以我在重构类提示词里特别加上“不改变任何现有测试用例的预期结果”，这一句话能倒逼模型在动手前先想清楚当前代码的“行为契约”是什么。如果项目缺测试，我还会再加一句“列出可能受影响的边界行为，供我补充测试”，比直接让它重构更稳妥。

4.3 重构后的验证清单

我每次做完重构，一定会让 WorkBuddy 再跑一轮“行为对照”——给我列两个表格，左边是重构前行为，右边是重构后行为，一行一行对照。这个思路其实是从后端兼容性测试里搬过来的。我发现只要让模型自己列这个清单，它就会主动去检查各种边界条件，比自己闷头重构严谨得多。

这个验证清单建议保存在 WorkBuddy 的工作台笔记里，它不只是给我自己看，也是给协作同事看——他们能清楚地知道这次重构没有改变任何使用方式，回归测试只需要关注原有功能即可。

5. 第四条可直接用的提示词：测试用例生成与边界探索

5.1 测试生成提示词模板

让 AI 帮你写测试，最大的风险是它只会写“happy path”——输入正常数据，断言正常输出，覆盖不到真实世界的角落。我的模板刻意要求它穷举异常和边界。模板如下：

请为以下函数生成完整的单元测试用例，采用 pytest 风格。 函数说明：该函数接收一个包含 startDate 和 endDate 的查询参数对象，返回日期范围内的工作日列表，含首尾两天。 文件路径：{project_root}/src/utils/getWorkdays.ts 生成要求： 1. 覆盖正常路径：常规日期范围、跨月、跨年。 2. 覆盖边界条件：startDate 等于 endDate、startDate 晚于 endDate、毫秒级时间差。 3. 覆盖异常输入：参数缺失、null、非法日期字符串、日期对象混用。 4. 覆盖时区问题：传入 Date 对象时的本地时区行为、传入字符串时的 UTC 解析差异。 5. 每个用例必须写断言，断言内容要具体到返回值而不是只判断是否为真。 6. 在文件开头用五行中文概述测试策略。 被测试函数： {代码粘贴}

这个模板最有价值的地方是第四条时区问题。大部分 AI 生成的测试用例根本没有时区意识，但实际生产环境里日期组件十个 bug 九个和时区有关。加上这一条后，它会主动生成“同一时刻在不同时区下的表现”的测试，保质期直接提升一个档次。

5.2 让测试可读、可维护、可跑通的细节

生成完测试用例后，我一般还会追加一个“可运行性检查”的指令：“请检查这些测试用例中是否有任何未定义的变量或 mock，列出所有测试运行前置条件，包括 fixture 的初始化方式。”AI 生成的测试代码经常漏掉 mock 或 import，直接运行时错误连篇。做完这个检查，用例的可执行性能大幅提升。

还有一个实操心得：让我生成测试用例时，给它“已通过但需审查”的心理暗示，而不是“请写测试”。同样一段函数，前者会生成更严格、更刁钻的用例，后者倾向于生成温和的用例。没有科学依据，但实测确实如此，可能是模型对“审查”二字的上下文联想导致的。你也可以试试看这个微妙的差异。

5.3 覆盖率的误区：追求行覆盖不如追求行为覆盖

用提示词写测试时，需要理解一个概念——代码覆盖率不等于有效覆盖。AI 最喜欢生成那种把 if/else 分支各跑一遍就完事的用例，行覆盖率看着挺高，但真正会出 bug 的组合情况完全没测到。所以我特别强调“行为覆盖”，就是让测试覆盖的是函数对外承诺的行为契约，而不是代码行的执行路径。

一个实际例子：有个函数处理订单金额，正常路径是数字相加，还有个隐藏行为是当金额超过 10000 时需要记录风控日志。行覆盖率测试跑不到这个隐藏行为（因为没有走日志初始化分支），但行为覆盖测试会专门构造大额订单，验证日志被写入。这就是“从需求出发”和“从代码出发”的测试设计区别。在提示词里明确“关注行为契约”，才能让 AI 生成真正有价值的测试。

6. 第五条可直接用的提示词：Skill 工作台编排与固化

6.1 Skill 描述提示词模板

WorkBuddy 的 Skill 机制是一种可复用能力，相当于把一段复杂的提示词封装成一个可调用的“技能”。比如你可以封装一个“代码审查官”Skill，一个“重构专家”Skill，后续只要触发 Skill 名，就能一键执行整套流程。我的 Skill 描述模板如下：

请帮我创建并注册一个名为“安全重构专家”的 Skill。 能力描述：该 Skill 专用于代码重构，重点在于保持行为不变。 适用场景：当用户希望重构一个函数、一个模块或一组文件，但又担心破坏现有功能时。 输入参数： - target_path：目标代码路径 - refactor_goal：重构的目标描述，如“提取公共逻辑”“降低圈复杂度” - risk_tolerance：风险容忍度，可选 low/high，默认 low 执行流程： 1. 读取目标文件并分析当前结构。 2. 输出重构前行为摘要，列出敏感边界条件。 3. 按“签名不变、行为不变、无新依赖”原则生成新代码。 4. 输出“重构前后变化对照表”。 5. 根据 risk_tolerance 的值，决定最终回复中是只列“关键改动”还是附带“全部 diff”。 输出规范：整套流程用中文，代码注释用中文。 验收标准：用户明确确认前，不直接覆盖原文件，只输出建议格式。

6.2 为什么要把提示词封装成 Skill：一次封装，终身受用

我自己最开始在图省事，直接在对话里复制粘贴那 5 条提示词，用多了发现很多内容是重复的。后来发现 WorkBuddy 支持把提示词体系固化到 Skill 里，才真正体会到“一次编排、处处调用”的爽感。就拿“代码审查官”来说，封装成一个 Skill 之后，我在任意项目里只要输入/audit 目标文件，它就会自动按审查维度、严重程度分级、续审机制跑全套流程，不用每次重复写提示词。

Skill 还能叠加在全局规则之上。全局规则是“静态的底线”，Skill 是“动态的流程”。两者互不冲突，反而是一个稳定的组合拳。我把最常用的 5 个场景全部做成了 Skill，日常工作和 WorkBuddy 的交互就退化成了“给路径、说目标、收结果”三步，效率提升非常明显。

6.3 Skill 的版本管理：提示词也需要迭代

忘了说一个关键经验：Skill 不是一次写对就不用管了，它和代码一样需要版本管理。我每个 Skill 都会在描述末尾加一个version: 2.1字段，每调整一次就升级。这样如果新版本行为异常，我可以回退到旧版本的 Skill 描述。我还养成了一个习惯：每次 Skill 版本更新后，用一个固定测试用例跑一遍回归，比如“对同样一段带时区 bug 的代码执行审计，确认输出仍然包含时区提醒”。这套测试驱动的思路，能让提示词本身也保持质量。

我看到很多人把 Skill 描述写得很文艺，比如“智能地分析代码并给出优雅的建议”，这完全没用。Skill 描述越像“操作手册”越有效，因为模型是靠描述里的动词和步骤来理解和调用的，而不是靠形容词。描述里写清“输入什么、输出什么、标准是什么”，它才能稳定执行。

7. 提示词实战避坑：那些一用就翻车的写法

7.1 规则被后续对话覆盖：用固化机制解决

全局规则最怕的就是被覆盖。有一次我设置了“不引入新依赖”，干了半小时后 WorkBuddy 突然开始推荐安装 dayjs，我回头排查发现它把对话里的某句话优先级理解得比全局规则更高了。实际上规则也是有“衰减”的，越往后的对话上下文越靠前，模型可能慢慢遗忘早先的规则。

解决办法是“重复激活”：每隔几轮对话，如果任务比较关键，我会在最后还是强调一遍“继续遵守全局规则，尤其是第 4 条不引入新依赖”。也可以在提问时直接把相关规则内嵌到提示词里，保证规则出现在上下文最近的位置。核心原则就是：越是关键红线，越要离任务描述近，越不要依赖“它应该还记得”。

7.2 上下文被无意义信息撑爆：精准投喂

WorkBuddy 的上下文窗口再大也不是无限大的，而且窗口越大，响应速度和生成质量都会下降。我见过有人把整个 README、整份接口文档、全部代码文件一次性塞进去，结果模型回答的每一句话都在绕圈子。这种“糊脸式上下文”和“缺失上下文”一样让模型崩溃。

正确的投喂方式是分层级：第一层是全局规则的地址，第二层是 Skill 的调用，第三层是本次任务的最小上下文。比如你想让它改某一个文件，就要刻意给它这个文件的路径、相关依赖文件和一处参考实现，而不是整个项目。我还会专门写一个“上下文裁剪”指令，提示它“忽略与当前任务无关的对话历史，专注当前文件和函数”。这个指令在实践中很管用，能有效对抗上下文污染。

7.3 提示词越长越好是错觉：聚焦才能出效果

我一开始以为把背景写全、要求写多、格式写细，模型就能给出完美结果。试过之后发现，超过一定长度的提示词，模型开始“过度解读”——把每条要求都执行到位，但整体方向偏了。比如让它“审查代码并优化”，审查和优化各占一半，两个都没做到极致。现在我更倾向于把一个超长提示词拆成两三条短任务：先审查，拿到报告后确认，再基于报告优化。

提示词真正的质量指标不是字数，而是约束与目标的匹配度。跟工作台协作有点像带一个实习生：你给的信息要完整但不冗余，方向要清晰但不僵化，还要给它随时提问或纠偏的窗口。摸到这套门道之后，WorkBuddy 才真正从一个玩具变成了生产力工具。

7.4 从零搭建自己提示词库的顺序建议

如果你是第一次接触 WorkBuddy，我建议不要一上来就追求“完美的全局规则+全家桶 Skill”。先用第 2 条“全局规则模板”搭一个最小底座，然后用第 3 条“代码审查模板”跑一个真实文件的审查，感受一下结构化输出的效果。用顺了之后，再把第 5 条“测试用例生成”和第 4 条“重构”结合起来，先用测试保障行为安全，再做结构优化。最后才封装 Skill，把你最常用的 2 到 3 个流程固化下来。

我个人的体会是，提示词库不是一次建成的，它跟着你踩过的坑一起成长。最开始我的 WorkBuddy 就是个高级 Chat 框，后来有一份全局规则，再后来有了 5 个 Skill，现在是连上下文投喂方式都形成了肌肉记忆。每一条好用的提示词背后，几乎都对应一次翻车后的复盘。

如果你也想复制这套打法，直接从第 2 节的全局规则开始，今天是星期一，改一版自己的规则出来，拿一个真实小任务试跑一遍，当天就能看出差别。剩下的审查、重构、测试、Skill，等基础稳了再逐个加进去也不迟。