企业官网建设流程全解析

用 WorkBuddy 这类可定制 AI 工作台有一段时间了，说句实在话，真正让我觉得“值回票价”的，不是模型版本换了多少次，而是手里攒下的那几条提示词。很多朋友拿到工具第一件事是装环境、配模型，结果跑了两天发现 AI 还是在同一个问题上反复犯傻——这往往不是模型不行，而是提示词没有把规则讲清楚。这篇文章把我实际在用、团队也在用的 5 条 WorkBuddy 提示词直接贴出来，附带每条提示词的设计思路和适用场景。如果你正在折腾 WorkBuddy、Cursor 这类 AI 编程工作台，或者单纯想提升自己和 AI 的沟通效率，可以拿来改一改就用。

1. 为什么 WorkBuddy 的提示词值得认真设计

1.1 先搞清楚 WorkBuddy 到底是什么

WorkBuddy 本质上是一个“自己可以搭规则”的 AI 工作台。它跟普通 ChatGPT 网页版的最大区别在于：你可以把长期有效的指令、技能模块和会话上下文绑在一起，让 AI 在每次开工前都先“读一遍规则”。说白了，普通聊天是“问一句答一句”，WorkBuddy 更像“先签劳动合同再干活”，它允许你把工作方式、输出格式、禁止事项都提前定好，然后后续所有任务都按这套规则执行。

很多用过 CodeBuddy、Cursor 的人上手 WorkBuddy 会觉得很亲切，因为它们都属于“提示词工程 + 上下文工程”的深度玩家。但 WorkBuddy 的特色在于 Skill 机制：你可以把一段高频使用的提示词打包成一个 Skill，像装配件一样在工作台里反复调用。写代码、写文档、审代码、拆需求，都能对应一个独立 Skill。这个设计非常合我的口味，因为 AI 编程最大的痛点从来不是模型不够聪明，而是每次会话都要重新“教育”一遍模型，费 token 不说，质量还不稳定。

1.2 提示词在 WorkBuddy 里起什么作用

提示词在 WorkBuddy 里不只是“提问”，它是上下文工程的核心部件。模型每次回答都受上下文影响，而上下文里最容易被忽略的就是“约束条件”。一个好的提示词 = 角色 + 任务 + 约束 + 示例，四样缺一不可。

举个例子，你直接问“帮我看看这段代码有什么问题”，模型大概率会给你一堆正确的废话，比如“请注意空指针”“建议增加日志”——因为它不知道你想要的审查深度，也不知道你关注性能还是安全。但如果你在 WorkBuddy 里预先定义好“代码审查 Skill”，模型就会按角色设定来工作，输出就稳定得多。这就像带新人：你说“随便看看”，他就真的随便看看；你说“按上线标准审查，重点看并发安全和越权问题”，他才会给你有含金量的反馈。提示词工程的价值就在这里，它把模型从“什么都会一点的实习生”变成“熟悉你项目的专职同事”。

另外，WorkBuddy 的全局规则和 Skill 还有一层隐藏价值：团队复用。你可以把一套写好的提示词导出，发给队友，大家的 AI 工作台就拥有同样的“工作情商”。这就相当于把个人经验变成了团队资产，而不是每次换人、换机器都重头摸索。

2. 五条可直接落地的 WorkBuddy 提示词

2.1 全局规则提示词：让 AI 做一个长期稳定的“同事”

这条提示词我放在 WorkBuddy 的全局规则里，它对所有任务生效。简单说，就是给 AI 定“人设”和行为边界，让它在整个工作台里保持统一的输出风格。

你是一个有十年一线开发经验的全栈工程师，现在加入我的项目工作台，和我一起完成软件开发、方案设计、代码审查等任务。 请遵守以下规则： 1. 所有回答先给结论，再给理由，最后给可执行方案； 2. 默认使用中文回复，代码注释使用中文； 3. 遇到不确定的信息，明确说“我不确定”，绝对不要编造； 4. 涉及代码问题时，先指出风险和边界，再给出代码； 5. 如果存在多种方案，用表格对比差异，并给出你的推荐项； 6. 不要重复我知道的背景信息，直接切入正题。

这条提示词的设计逻辑是“身份 + 行为边界”。为什么强调先给结论？因为 AI 默认喜欢罗列选项，显得自己很全面，但工程决策最怕的就是“你说了半天，到底选哪个”。加了第 1 条之后，模型会先掷地有声地告诉你结论，你不想看理由时可以直接跳过。第 3 条也很关键，AI 编造信息的最大原因是你没告诉它“不知道就说不知道”。

我建议把这条做成一个全局规则，而不是放在某个 Skill 里。因为它影响的是 AI 的底层行为方式，一旦拆散到各个 Skill 中，就起不到“对所有任务生效”的作用了。实测下来，有了这条规则之后，模型回答的废话量明显减少，特别是被我追问“哪个方案更好”时，它不再踢皮球了。

2.2 需求拆解提示词：把一句话变成任务清单

产品扔过来一句话需求，是每个开发都头疼的事。这条提示词就是为了解决“需求太模糊”的问题。我把它做成一个 Skill，使用的时候只要把需求原文填进去，AI 就会自动拆解成任务清单。

接下来是一个需求描述： <在这里粘贴需求原文> 请基于以上需求，帮我拆解成可执行的任务清单。要求如下： 1. 每个任务必须有明确目标和完成标准； 2. 标注任务之间的依赖关系，谁必须先做，谁可以并行； 3. 为每个任务估算复杂度（低/中/高）； 4. 识别需求中模糊、冲突、缺失的点，并给出追问列表； 5. 输出格式：先用表格展示任务清单，再用 3-5 句话说明整体实施顺序。

这条提示词的核心在于“结构大于自由发挥”。模型本身很擅长干这事，但如果不规定输出格式，它可能会给你一段洋洋洒洒的散文，看完更懵。用表格约束后，任务清单一目了然，我可以直接复制到项目管理工具里用。

实际使用时有几个小技巧。第一，需求原文一定要原样粘贴，不要先用自己的话转述一遍，否则 AI 会被你的转述带偏，丢失原始需求里的细节。第二，如果需求特别短，比如只有“做个登录功能”五个字，你也可以在提示词后面追加一句“如果需求信息不足以拆解，请先输出你需要的补充信息”，这样 AI 就不会硬拆，而是先追问你。第三，这个 Skill 的价值不只是拆解，它顺带帮你做了需求评审——第 4 条要求输出追问列表，等于让 AI 帮你把产品的话术和漏洞都先过一次。

2.3 代码审查提示词：让 AI 带着“挑刺”的心态读代码

代码审查是 AI 编程工作台最实用的场景之一。但我发现很多人用 AI 审代码，得到的反馈总是“代码整体良好，注意优化性能”这种不痛不痒的话。问题出在提示词没有把“审查标准”讲清楚。我用的这条提示词：

你正在代码审查模式下工作。请审查下面这段代码（或代码变更），并按照以下维度逐个检查： 1. 正确性：是否存在明显的逻辑错误、边界条件遗漏、并发问题？ 2. 安全性：是否存在注入、越权、敏感信息泄露、参数未校验等问题？ 3. 可维护性：命名是否清晰、函数是否过长、是否存在重复代码？ 4. 性能：是否有明显可以优化的热点，但不要求过度设计； 5. 兼容性：是否考虑了不同环境或依赖版本的影响。 输出要求： - 先给出总体结论（通过 / 有条件通过 / 不通过）； - 然后按严重程度列出问题列表：严重、一般、建议； - 每个问题必须给出代码位置、问题说明和修改建议； - 如果审查的代码没有问题，请直接说明“未发现明显问题”，不要为了凑数而提建议。 代码内容如下： <粘贴代码>

第 3 条是我最看重的：不让 AI 为了“提建议”而提建议。这个限制非常重要，因为模型天生倾向于“有话可说”，如果没有这条约束，它会把一些无关痛痒的编码风格问题标成严重问题，反而淹没了真正的 Bug。加了这条之后，输出干净多了，严重问题一目了然。

另外提醒一件事：不要把整个项目代码一次性丢进去，上下文窗口和分析精度会互相打架。我一般是一次审查一个文件或一个函数，最多带上相关的一两个依赖函数。如果确实要做全面审查，就拆成多次调用，让每次审查都聚焦在一个模块上。这样审查质量会明显高过一个“什么都想看”的大杂烩会话。

2.4 提交信息与更新日志提示词：治理 Git 提交历史

这条提示词看起来不起眼，但它是团队协作中回报率最高的一个。提交信息写得乱，后面查历史、做 release notes、定位问题都痛苦。我把这条做成一个 Skill，配合代码 diff 使用，几秒钟就能生成一条规范的提交信息。

根据下面的 Git diff 内容，生成一条 commit message。要求： 1. 采用 Conventional Commits 格式：type(scope): subject； 2. type 只能从 feat、fix、refactor、docs、test、chore、perf、style 中选择； 3. subject 使用中文，不超过 20 个字，禁止使用“更新”“修改”这类笼统动词； 4. 如果 diff 包含破坏性变更，必须在 message 末尾加 BREAKING CHANGE 说明； 5. 如果有多个不相关的改动，请拆成多条 commit message，而不是合成一条。 Git diff： <粘贴 diff 内容>

第 3 条的“禁止使用笼统动词”是我后来加进去的，因为 AI 默认会生成“更新了代码逻辑”这种话，对排查问题没有任何帮助。加了这个限制后，它就会老老实实写“修复用户列表分页时丢失查询参数”这种能看懂的话。

这个提示词还有一个升级用法：你可以让它同时生成 changelog。在提示词末尾加一句“请同时生成一条面向用户的 changelog 描述，语言通俗、突出用户可见变化”，就能把 commit message 和 release notes 一次搞定。跑版本发布的时候，我基本就是从 AI 生成的结果里筛选拼接，效率比之前手写不知道高到哪里去了。

2.5 模型能力自测提示词：用“鹈鹕骑车”式问题避免幻觉

这条提示词比较特别，它不是直接用来干活的，而是用来“测试模型”的。我知道很多人会觉得奇怪，但我会认真解释为什么这很重要。

如果你经常切换不同模型来跑 WorkBuddy，你会发现不同模型的理解能力、防幻觉能力差很多。同样一段代码审查提示词，模型 A 给的建议可用度很高，模型 B 却在强行编造一个不存在的函数。与其等到写代码时被坑，不如在切换模型后先做一次快速自测。网上流传的“鹈鹕骑自行车”测试题，本质上就是这个用途。

适合 WorkBuddy 的自测提示词可以这么写：

请判断下面这个场景是否合理，并一步一步说明理由： 一只鹈鹕骑着自行车在沙滩上行驶，嘴里还叼着一条鱼。 要求： 1. 如果场景合理，请描述它的动作细节； 2. 如果场景不合理，请明确指出是哪些环节违反了物理常识； 3. 不要为了迎合用户而强行把不合理解释成合理； 4. 回答控制在 200 字以内。

这个题目的妙处在于：场景本身“离谱”但又不是完全不可能，模型如果老老实实分析“鹈鹕没有适合操作踏板的身体结构”“脚掌不适合保持平衡”，说明它具备基本的常识推理能力；如果模型为了讨好你，把“鹈鹕用喙咬着车把、翅膀扇动提速”描述得栩栩如生，那你就要警惕了——它在正式任务里也很可能给你编出一个看起来很真、实际不存在的接口。我实测过，不同模型对这道题的反应确实差别很大，拿它当“试金石”非常管用。

要注意的是，这类测试不是为了刁难模型，而是为了建立你对当前配置的信任度。如果模型自测表现不好，不应一味怪模型，而是可以给它补充约束规则，比如前面 2.1 里的“不确定就说不知道”，再跑一次测试看看改善情况。这样测试就从“吐槽大会”变成了“配置调优的手段”。

3. 把提示词落地到 WorkBuddy 工作台

3.1 安装与初始化的一种省心路径

前面给的提示词再好，不落地到 WorkBuddy 环境里也白搭。先说一下我这边比较顺的初始化路径。

WorkBuddy 在 Windows、macOS 上都能跑，网上也有不少安装教程。我的建议是安装完第一件事不是去选模型、调试参数，而是先把全局规则设好。因为一旦你在普通会话模式下跟它聊了很多内容，AI 会把这些零散上下文“记住”，后面再加规则时，它会混淆到底哪些有效。干净开局是最好的起点，就像新装系统之后先装杀毒软件和输入法，而不是先把游戏装满。

打开设置里的全局规则编辑器，把 2.1 那条提示词原样贴进去。保存后，建议新建一个测试会话，随便问一个工作相关的小问题，看看它是否遵守“先结论后理由”的格式。如果没反应，检查一下是不是配置面板里还有一个“对已有会话生效”的开关，把它打开。我自己第一次就漏了这个开关，测试了半天以为提示词写错了，结果只是面板没勾选。

3.2 将高频提示词沉淀为 Skill，而不是每次复制粘贴

全局规则设定好之后，接下来的四类高频动作（需求拆解、代码审查、提交信息生成、模型自测）就不适合往全局规则里塞了。因为全局规则如果太长，模型会“读不进去”，表现为后面的任务越来越不遵守前面的规则。正确做法是把它们做成 Skill，按需调用。

在 WorkBuddy 里新建 Skill 时，有几点操作细节值得注意。

第一点，Skill 命名用动词开头，比如 task-split、review-code、commit-msg、model-sanity-check。这种命名方式在会话中自然触发时准确率更高，模型更容易把抽象的技能名和具体的任务场景对应起来。

第二点，Skill 描述里不要只写“代码审查”，要写清楚“审查指定代码或代码变更并输出问题列表”。描述写得越像“我是干什么的”，模型调用时命中率越高。这一点和搜索引擎原理有异曲同工之处：你自己怎么搜不到，大概率是你的关键词没描述清楚。

第三点，把我上面每条提示词中的“<粘贴内容>”部分都做成参数占位符。比如代码审查 Skill 的输入参数就是“待审查代码”，提交信息 Skill 的输入参数就是“Git diff”。这样调用时只需要填参数，不用再去修改提示词正文，省事且不易出错。

3.3 工作台参数与缓存目录设置

还有一个大家经常忽略的地方是 WorkBuddy 的缓存清理。这个工具会把模型缓存、历史会话、技能索引都放在系统盘对应的用户目录里，用久了之后体积能涨到好几个 GB。尤其是你频繁切换模型、调试 Skill 的时候，缓存增长得特别快。

很多人问“WorkBuddy 系统缓存目录能不能改到 D 盘”，答案是可以的。在设置里能找到缓存路径选项，手动改成 D 盘的一个英文路径，比如 D:\workbuddy_cache，然后重启工作台生效。改完有两个好处：一是系统盘空间压力小了，二是重装系统保缓存，历史技能和配置不容易丢。但要注意路径不要带中文，也不要放在带有权限控制的系统目录附近，否则会莫名其妙出现读不到缓存文件的问题。如果你发现自己改了路径后 Skill 加载变慢，大概率是新目录和旧目录产生了权限冲突，把旧缓存清掉重新生成就好。

一个小提醒：如果你用的是老版本系统，比如 Win7，能正常打开、基础功能可用，但新版模型的体验会受限。我的建议是能升级就升级，不能升级就把 WorkBuddy 的版本固定在兼容版，不要追新。这个不是玄学，是很多组件库的底层要求确实变高了。

4. 实操中踩过的坑与排查实录

4.1 全局规则被“带偏”的原因和解法

我使用中发现一个特别容易踩的坑：全局规则设定得好好的，可一旦你在某个会话里用自然语言说了一句“忽略刚才那条规则”或者“别管那些限制了”，模型就会真的把全局规则当成“刚才那条规则”一起忽略掉。虽然我们人类很清楚这只是针对本次对话的临时修改，但模型并不擅长区分“全局规则”和“临时指令”的优先级。

解决办法是我后来摸索出来的：遇到临时需要打破规则的场景，不要用否定句式，要明确说“本会话内暂停 X 规则，其他规则继续生效”。同时，最稳妥的方案是直接在当前会话关闭 Skill 调用，或者新开一个会话，而不是试图用自然语言“精准修改”模型的行为边界。前者是规则引擎层面的事，后者只靠模型自觉，稳定度完全不同。

另外，全局规则里尽量不要写“永远不要”“绝对不要”这类重话。模型对绝对化表述反而容易走极端，要么过度执行、什么事都不敢做，要么直接忽略。更好的写法是“除非我明确要求，否则不要 X”，给规则留一个可被指令覆盖的出口。

4.2 提示词过长反而失效

这个问题通常出现在“胡子眉毛一把抓”的时候。我曾经为了省事，把全局规则、需求拆解、代码风格、测试要求全并到一个 Skill 里，结果模型输出质量一落千丈。后来仔细看输出才意识到：提示词太长，模型在处理后面的任务时，常常只记得开头和结尾的内容，中间的规则直接丢了。

这不是模型“笨”，而是注意力分布本来就是偏向前后、弱化中间。所以我现在严格执行“一个 Skill 只负责一类任务”的规范。2.2 需求拆解提示词只拆需求，2.3 代码审查提示词只审代码，绝不在一个 Skill 里塞两个不相干的功能。如果确实需要多个能力组合，就在 WorkBuddy 里定义一个工作流顺序，让两个 Skill 依次执行，而不是拼成一个巨型提示词。

还有一个相关技巧：如果提示词里有一堆规则，把最重要的约束放在第一条和最后一条。这利用了模型对上下文两端更敏感的天然特性，虽然不“高级”，但在实践中非常有效。

4.3 遇到输出幻觉和重复时要检查什么

我用的模型偶尔会出现一种情况：连续几次输出高度重复的内容，有时候还会把前一个任务的信息带到后一个任务里。第一次遇到时，我以为是提示词写错了，后来排查发现是缓存目录里的旧会话碎片导致的上下文污染。

这种时候按顺序做几步检查：第一步，新建一个空白会话，不带任何历史记录测试同样的问题，看是否还重复。如果恢复，说明是当前会话上下文被污染了；如果依旧，说明问题出在提示词层面。第二步，清理 WorkBuddy 缓存，把系统盘下那个工作台缓存文件夹里的历史索引清掉，重启再试。第三步，检查是否多个 Skill 之间定义了同名参数，有些版本会因此产生参数覆盖，导致模型读取到错误的值。

这三步能解决我碰到的九成怪问题。说句大实话，很多所谓“AI 突然变笨了”的时刻，根本原因是会话和缓存里的残留信息在作怪，而不是模型本身出了问题。养成“定期清理缓存、一个会话一个任务”的习惯之后，WorkBuddy 的整体稳定性会有肉眼可见的提升。

最后再分享一点个人体会：这 5 条提示词不是一次写出来的，它们是反复试用、被现实锤过之后的沉淀。提示词跟代码一样，也需要版本管理，也需要按项目、按团队口味裁剪。你先照着用一周，再把自己的使用习惯和方法论融进去，那才是真正属于你自己的 WorkBuddy 工作台。