企业官网建设流程全解析

1. 先把这玩意儿搞明白：AI工作台的定位与选型逻辑

WorkBuddy 这类 AI 工作台，本质上不是"又一个聊天窗口"，而是把大模型能力塞进日常办公流的中间层。它把"对话"变成"指令"，把"指令"变成"技能"，再把"技能"挂到文件、表格、日历、邮件这些真实载体上。我第一次接触它的时候，最直观的感受是：终于不用每次开会前手动整理一堆散落的访谈记录了。它解决的问题很具体——重复性文本劳动的结构化，包括会议纪要归整、周报汇总、需求文档初稿、表格字段清洗、跨语言材料对齐这类"不难但磨人"的活。适合谁来学？三类人最受益：一是每天要处理大量文档和表格的业务岗，二是想把团队 SOP 沉淀成可复用资产的项目管理者，三是有一定脚本基础、想给内部工具加一层智能外壳的开发者。零基础也能上手，前两章基本不涉及代码。

1.1 它和聊天式 AI、自动化脚本的边界在哪

很多人第一反应是"我用网页版对话也能干这些，为什么要装一个客户端"。我拿三个场景对比过，差距很明显。第一个场景是上下文连续性：网页对话关掉就散了，工作台的指令可以带固定上下文，比如"永远参考我附上的术语表"，每次调用自动带上，不用重复粘贴。第二个场景是落地动作：聊天只能给你一段文字，你还要自己复制、改名、存进文件夹；工作台的技能可以直接写文件、读表格、按规则重命名。第三个场景是一致性和可审计：同一份周报，五个人写出来五个样，工作台可以把输出模板锁死，格式统一，改版也有记录可查。

看清楚这张表，你就知道该在什么位置用它。规则明确、格式固定的批量任务交给脚本；内容需要理解、归纳、重写的任务交给工作台；两者交界的地方，让工作台调脚本，或者脚本触发工作台。

1.2 为什么值得专门花时间学"指令"和"技能"

我见过不少团队买了工具，用两周就荒废了，原因几乎一样：大家还在用"对话框思维"使唤它——想到什么问什么，问完复制走，下次重来。这种用法下，工具的价值上限就是"打字快一点的搜索引擎"。真正拉开差距的是两件事：把高频任务的提示词固化下来，以及把多步操作串成一次点击。

我做过一个粗略统计，同一个"把访谈录音转写稿整理成结构化纪要"的任务，用自由对话的方式，平均要来回 4 到 6 轮才能拿到能用的结果，耗时 12 分钟左右；用调好的自定义指令，一次出稿，人工只做 2 分钟校对。一周十场访谈,省下来的时间够你写两份正经方案。这就是为什么第 3 章和第 4 章占的篇幅最大——它们是这套工具真正的杠杆点，安装只是入场券。

1.3 版本与账号体系怎么选

不同版本能力差异主要集中在三块：可用的模型档位、技能数量上限、以及数据是否出本地。我建议按这个顺序决策：

• 先确认数据边界：材料涉不涉及敏感信息，能不能出内网，这决定你选本地处理还是云端处理。
• 再看协作需求：一个人用，个人版足够；需要共享指令和技能给同事，必须上团队版，否则每个人都在重复造轮子。
• 最后看模型档位：日常的摘要、改写、格式转换，中档模型完全够用；涉及长文档深度推理、复杂表格逻辑校验，才需要往上调。别一上来就开最高档，成本和等待时间都不划算。

提示：账号体系里有个容易被忽略的点——工作区的概念。指令、技能、文件索引通常绑定在工作区下，换工作区等于换一套环境。团队协作时先约定好工作区命名规则，比如"部门-用途-环境"，后期迁移会省很多事。

2. 安装与初始配置：从下载到第一次跑通

这一章我把踩过的坑按顺序摆出来。安装本身不复杂，麻烦都在"装完之后它不好用"这个阶段，八成是初始配置没做对。

2.1 环境基线：别在配置上省事

官方一般会给最低要求，但最低要求只保证"能打开"，不保证"能干活"。下面这份是我实测下来比较舒服的配置，供参考（不同版本可能略有差异，以安装包的说明为准）：

有一个细节值得单独说：如果你的机器上装了多个版本的运行时环境或虚拟环境，安装前先确认 PATH 干净。我遇到过一次装完之后技能里的脚本调用总是走到旧版本解释器上，排查了两个小时才发现是环境变量顺序问题。装之前把终端打开，敲一下版本命令确认，比装完再救火省事得多。

2.2 安装步骤与目录结构

流程本身很直白，关键是每一步的校验动作：

1. 下载安装包，优先走官方渠道，别用来路不明的第三方镜像。
2. 做一次完整性校验，比对官方公布的校验值。这一步很多人跳过，但企业环境里出过一次包被中间环节替换的事故，从此我必校验。
3. 执行安装，Windows 建议装到非系统盘的用户目录下，macOS 直接拖入应用程序目录。
4. 首次启动，注意观察启动日志里有没有报错，尤其是权限相关的。
5. 确认数据目录位置，这个后面会反复用到。

装完之后一般会在这几个位置生成内容，理解它们的作用，出问题时能快速定位：

<用户目录>/.workbuddy/ ├── config/ # 全局配置、模型档位、代理设置 ├── instructions/ # 自定义指令，通常一个指令一个文件 ├── skills/ # 技能定义与依赖 ├── workspace/ # 工作区文件索引与临时产物 ├── cache/ # 模型响应缓存，可安全清理 └── logs/ # 运行日志，排查问题的第一现场

注意：cache和logs是可以定期清的，config、instructions、skills千万别手贱删。我见过有人为了"清干净重装"，把整个目录一删，结果三个月调好的指令全没了。养成习惯：改指令前先复制一份带日期后缀的备份。

2.3 首次登录与工作区初始化

登录之后别急着提问，先把工作区建好。我的习惯是按用途分，而不是按人分：

• personal-draft：个人草稿，随便折腾
• team-docs：团队共享，指令和技能放这里
• batch-jobs：批处理专用，避免污染主工作区

建完工作区，第一件事是指定一个默认参考目录。工作台的检索能力依赖文件索引，如果没有明确索引范围，它在回答"帮我找一下上次那份方案"时会把整个磁盘扫一遍，既慢又容易命中无关文件。索引范围收窄到两三个目录，效果立竿见影。

第二件事是跑一个最小闭环：随便丢一段五百字的材料进去，让它做一次摘要。这一步的目的不是看它聪不聪明，而是验证"输入—处理—输出—保存"这条链路是通的。链路不通就往下走，后面全是白费功夫。

2.4 必做的五项初始设置

这五项我每台机器装完都会改，改完体感差别很大：

第一，默认输出格式。默认往往是自由文本，改成带明确结构的形式，比如"先给结论，再给依据，最后给待确认项"。这样你拿到的每一份输出都是同构的，后期做汇总特别省事。

第二，上下文长度策略。长文档场景下，默认值可能不够，但也不是越大越好——上下文塞太满，模型对中间部分的注意力会下降。我的经验是：单次任务控制在"核心材料 + 必要背景"两部分的量，超出的部分拆成多轮。

第三，快捷键。全局唤起键一定要改，默认组合经常和输入法、截图工具打架。改成一个你手指记得住、又不冲突的组合，使用频率会明显上升。

第四，自动更新策略。团队协作场景建议关掉自动更新，改成手动。原因很现实：某次自动更新改了指令语法，第二天全组的技能集体失灵。

第五，日志级别。调成"信息"级别并保留最近七天的日志。平时占不了多少空间，出问题时就是救命稻草。

3. 自定义指令：把"每次都要说一遍"变成"开口即对"

自定义指令是整个工作台里投入产出比最高的东西。它的价值不在于让模型更聪明，而在于消除你每次都要重复交代的那些背景信息。写得好，等于给自己配了个记得住所有上下文的老搭档；写得糙，等于给模型套了个枷锁，输出还不如自由对话。

3.1 指令的四层结构：角色、任务、约束、输出格式

我把所有能长期用下去的指令，都拆成四层。缺一层，输出就会在某方面失控：

• 角色层：明确它站在什么位置说话。不是"你是资深专家"这种空话，而是"你是一位负责需求评审的产品负责人，习惯先质疑再补充"。具体到职责和行为倾向，输出风格才会稳。
• 任务层：一句话说清要干什么，动词要具体。"整理"、"提取"、"校验"、"改写"比"处理"、"优化"这种模糊词有效得多。
• 约束层：这是最容易被忽略、又最影响可用性的一层。包括：字数范围、必须包含哪些要素、绝对不能出现什么、信息缺失时怎么办。
• 输出格式层：给出明确的骨架。要么用固定小标题，要么用字段列表，要么用表格结构。能给出示例就给示例，哪怕只有两行，模型对齐格式的准确率会高一大截。

举个我常用的对比。粗糙版写的是"帮我整理会议记录"，输出忽长忽短，有时给段话，有时给一堆要点。调整后是这样：

# 角色 你是一位负责项目推进的协调人，习惯把讨论落到"谁在什么时候做什么"。 # 任务 把下面的会议转写内容整理成结构化纪要。 # 约束 1. 只使用原文出现的信息，不补充、不推测。 2. 发言人姓名若不确定，用"发言人1/2"代替，不要臆造。 3. 决议事项必须能对应到原文的具体表述。 4. 未形成结论的分歧点单列为"待确认"，不要强行给结论。 5. 总篇幅控制在 600 字以内。 # 输出格式 ## 会议主题 ## 参会角色 ## 核心结论（不超过 5 条） ## 行动项 | 事项 | 责任人 | 时间节点 | 来源依据 | ## 待确认分歧 ## 原文存疑处

这版指令我用了大半年，几乎不用改。关键在那几条"不"字开头的约束——它们决定了下限。很多人写指令只写"要做什么"，不写"不许做什么"，结果模型就自由发挥，自由发挥就意味着不可控。

3.2 参数化写法：让一条指令适配多个场景

每条指令都硬编码具体信息，维护起来会要命。正确做法是留占位符，调用时填。常见的占位方式是用双花括号标记：

# 任务 针对 {{材料类型}} 做一次 {{处理目标}} 处理，读者是 {{目标读者}}。 # 约束 - 专业程度：{{专业程度}}（可选值：面向新人 / 面向同行 / 面向管理层） - 篇幅：{{篇幅}} 字左右 - 若材料中缺少判断所需的关键信息，先列出缺失项，不要自行补充

这样一条"材料处理"指令，可以覆盖方案评审、周报汇总、培训材料改编三种场景，只是调用时换参数。工作台里通常支持把常用参数组合存成预设，一点就填好。

再说条件分支，这是把指令写得像程序的地方：

若输入内容中包含表格： 先用一段话说明表格表达的核心结论，再逐行解释异常数据。 若输入内容中不含表格： 直接按"结论—依据—建议"三段式输出。

听起来简单，但这一条能解决"有时候输出结构完全不匹配"的困扰。模型不怕任务复杂，怕的是任务边界模糊，你替它把分支划清楚，它反而更稳。

3.3 六个可以直接抄的指令模板

下面这几条是我实际在用的，改改字段就能落地。

模板一：周报归并

# 角色：团队协调人 # 任务：把多位成员的本周记录合并为一份部门周报 # 约束 1. 合并同类项，相同工作不要重复列出。 2. 保留原始进度描述中的量化数据，不做模糊化处理。 3. 存在阻塞项时，单独成节并标注影响范围。 4. 不评价成员表现，只陈述事实。 # 输出格式 ## 本周整体进展（3 句话以内） ## 分项进展 ### 事项名称 | 进度 | 关键数据 | 阻塞 ## 风险与阻塞 ## 下周重点（不超过 5 条）

模板二：需求文档初稿

# 角色：需求分析 # 任务：根据 {{需求描述}} 生成需求文档初稿 # 约束 1. 每条需求必须能被验证，避免"体验更好""更流畅"这类无法验收的表述。 2. 无法从输入中确定的信息，统一列入"待澄清"，逐条列出问题。 3. 不设计技术实现方案。 # 输出格式：背景 / 目标用户 / 使用场景 / 功能点（含验收标准）/ 边界与不做 / 待澄清

模板三：长文压缩

# 任务：把 {{原文}} 压缩到 {{目标字数}}，保留全部关键结论与数据 # 约束 1. 删除修饰、重复、举例性内容，保留判断句和数字。 2. 不得引入原文没有的结论。 3. 专业术语保持原样，不做通俗化改写。

模板四：表格字段清洗规则说明

# 任务：检查 {{表格}} 的字段一致性，输出清洗规则建议 # 约束 1. 逐字段说明：当前取值形态、存在的问题、建议规则、影响行数。 2. 只提出规则，不直接修改数据。 3. 对可能误伤正常数据的规则，必须标注风险。 # 输出格式：表格（字段名 / 问题类型 / 建议规则 / 影响范围 / 风险等级）

模板五：代码评审意见整理

# 角色：负责合并把关的开发 # 任务：整理 {{代码变更说明}} 中的评审意见 # 约束 1. 按严重程度分为"阻断 / 建议 / 讨论"三档。 2. 每条意见必须包含：问题位置、问题描述、建议改法。 3. 不确定是否为问题的，归入"讨论"，不下结论。

模板六：跨语言材料对齐

# 任务：对 {{源文档}} 与 {{译文档}} 做一致性核对 # 约束 1. 逐段对照，标注漏译、增译、术语不一致三类问题。 2. 术语不一致需列出原文用词与译文中出现的所有变体。 3. 不评价翻译质量好坏，只做事实性比对。

3.4 指令调试与版本管理

写完指令不等于完事，还得调。我的调试习惯是用三个样本压测：一个标准样本、一个极端样本（特别长或特别短）、一个脏样本（格式混乱、有错别字、信息残缺）。三个样本都能过，这条指令才算可用。标准样本看格式对不对，极端样本看会不会截断或跑题，脏样本看它的容错能力——很多指令死在脏样本上，输出开始自行编造缺失信息。

版本管理别搞复杂了，文件名加日期和用途就行，比如meeting-summary_v3_20250110.txt。改动幅度大的时候，保留旧版本对照跑一遍，确认新版本在所有样本上都不退化再删旧的。这个习惯救过我一次：某次为了让输出更简洁调了约束，结果把"待确认项"那一节给挤掉了，好在有旧版本对比，一眼看出来问题。

提示：指令里少用绝对化措辞，比如"必须严格""绝对不能有任何偏差"。过度强硬的约束反而会让模型在信息不足时硬编内容来"满足要求"。用"信息缺失时列为待补充"这种有出口的表述，稳定性高得多。

4. 技能实战：把重复动作封装成一次点击

指令解决"说什么"，技能解决"做什么"。如果一条任务你一周要跑三次以上，并且步骤固定，就该把它做成技能。技能的本质是把"读文件—处理—写文件—通知"这条链路固化下来，中间不需要人盯着。

4.1 技能的四个组成部分

不管界面长什么样，技能拆开都是四块：

理解这张表很关键：绝大多数技能事故不是模型不行，是输入输出没定义清楚。比如输入写成"处理收件箱里的文件"，结果把别人放进去的临时文件也处理了；输出直接写同名文件，第二轮跑就把第一轮的结果覆盖了。

4.2 从零做一个"会议纪要归档"技能

拿一个最典型的场景走完整流程：每周若干场访谈，转写稿散在一个目录里，需要产出结构化纪要并按日期归档。

第一步，定输入。目录锁定为inbox/transcripts/，只处理.md和.txt，文件名格式约定为日期_主题.txt。文件名不合规的直接跳过，并写一条日志。这一步看着啰嗦，但能挡住 80% 的脏数据。

第二步，定处理链路。分三段：

1. 读取与预处理：去掉转写工具带的时间戳噪声、合并断行、识别说话人。
2. 结构化抽取：套用第 3 章那条会议纪要指令，输出固定结构。
3. 校验：检查是否包含"行动项"和"待确认"两节，缺了就标记为待人工复核，不进入归档目录。

第三步，定输出。路径规则用archive/{年}/{月}/{日期}_{主题}_纪要.md，重名时自动加序号而不是覆盖。同时在archive/index.csv里追加一行索引，方便后期检索。

第四步，定异常处理。三类异常分开处理：读取失败重试两次；抽取结果校验不过转人工队列；写盘失败（权限或磁盘满）直接告警停跑。宁可停，不可错——这是批处理的基本原则，错误的归档比没归档更麻烦。

伪代码大致长这样，实际落地时按平台提供的节点拼就行：

for f in list_files("inbox/transcripts", exts=[".md", ".txt"]): meta = parse_filename(f) # 日期_主题 if not meta: log_skip(f, "命名不合规"); continue raw = read_text(f) if not raw.strip(): log_skip(f, "内容为空"); continue clean = strip_timestamps(raw) result = run_instruction("meeting-summary_v3", {"content": clean}) if not has_sections(result, ["行动项", "待确认分歧"]): move_to(f, "review/pending"); continue out = build_path("archive", meta.date, f"{meta.date}_{meta.title}_纪要.md") safe_write(out, result) append_index("archive/index.csv", meta, out)

第五步，跑三轮。第一轮只放一个文件，人工核对结果；第二轮放五个不同格式的，看鲁棒性；第三轮全量跑，观察耗时和失败率。别跳过小步验证直接上全量，我干过一次，二百多份稿子跑完才发现归档路径少了一层年份目录，全部重来。

4.3 表格处理技能：校验与异常报告

第二个高频场景是表格。表格处理比文本处理更需要克制，原因是数据错了不容易发现。我的做法是：技能只做校验和报告，修改动作交给人确认。

技能逻辑分四步：读入后先识别表头与数据类型；然后逐字段跑规则校验，比如手机号位数、日期格式、枚举值范围、必填项是否为空；再跑跨字段一致性，比如"结束日期不早于开始日期"、"金额等于单价乘数量"；最后输出一份异常清单，包含行号、字段、异常类型、建议处理方式。

RULES = { "日期": lambda v: matches(v, r"\d{4}-\d{2}-\d{2}"), "状态": lambda v: v in {"待处理", "进行中", "已完成"}, "数量": lambda v: is_number(v) and float(v) > 0, "开始日期": None, # 参与跨字段校验 } issues = [] for idx, row in enumerate(rows, start=2): # 从数据首行算起 for field, rule in RULES.items(): if rule and not rule(row.get(field, "")): issues.append((idx, field, "格式不符", row.get(field))) if row.get("开始日期") and row.get("结束日期"): if row["结束日期"] < row["开始日期"]: issues.append((idx, "日期区间", "结束早于开始", ""))

输出报告时有个小技巧：按异常类型分组，而不是按行号排序。因为人的处理方式是"把所有的日期错误一次性改完"，按行号排会让人来回翻。这个细节是我改了三版之后才想明白的。

4.4 技能的组合与幂等设计

单个技能用顺了，自然会想串起来：先做纪要，再做汇总，最后发通知。串联时有三个原则必须守：

一是幂等。同一个输入跑两次，结果应该一致，副作用只发生一次。做法是给每个处理过的文件生成一个指纹（文件内容哈希加处理版本号），处理前先查记录，已处理过的直接跳过。没有这一条，重跑一次就多一份重复归档。

二是失败可见。串行链路里任何一步挂了，要能明确知道挂在哪一步、影响哪些文件。我的做法是每一步都写一行状态日志，格式统一为"时间 / 步骤 / 文件 / 状态 / 备注"，出问题时grep一下就能定位。

三是可回滚。输出目录按批次分文件夹，比如archive/batch-20250110-01/。整批出问题直接删文件夹重跑，不会污染历史数据。这条比什么都重要，我吃过一次苦头：技能把错误的模板应用到了一批已归档文档上，因为没有批次隔离，只能一个一个找回原文件。

5. 常见问题与排查实录

这一章是纯经验。下面这些问题我几乎全踩过，有些还踩了不止一次。

5.1 高频问题速查表

5.2 四个印象最深的坑

坑一：上下文超限导致的静默截断。最开始处理长材料，我以为超长会报错，实际是悄悄截断，输出看着完整，但后半部分根本没被考虑进去。后来养成习惯：输入超过一定长度，先做一次分段摘要，再拿摘要做二次处理。这种做法有个副作用——二次摘要会丢细节，所以关键数据要单独抽出来做校验表。

坑二：JSON 输出带围栏。让模型输出结构化数据，它经常给你包一层代码块标记，解析直接报错。解决办法不是写更复杂的正则，而是在指令里明确"只输出 JSON 本体，不要任何标记符号"，再在解析端做一次兜底清理。指令端和解析端都做防护，比在一端死磕强。

坑三：权限问题的表现极具迷惑性。技能在开发机上跑得好好的，换到同事机器上就失败，日志显示"写入失败"。查了半天发现是目标目录在同步盘里，同步程序占着文件句柄。这类问题的排查思路是：先在命令行手动执行同样的写操作，看能不能成功，能成功就是程序问题，不能成功就是环境问题。先分清是代码还是环境，能省一半时间。

坑四：迭代过程中把旧能力改没了。调指令时最容易犯的错是"修一个坏两个"。我现在的做法是维护一个回归样本集，五到八个典型输入，每次改完指令全套跑一遍，逐条对比输出差异。听上去笨，但比上线后才发现退化要划算得多。

5.3 性能与成本的优化思路

优化不是一味降配置，而是分层处理。我的做法是三段式：先用规则过滤，再用小模型粗筛，最后用强模型精加工。

规则过滤处理那些明显不需要模型的内容，比如空文件、格式完全不符的、已经处理过的。这一步能砍掉两三成的无效调用。粗筛阶段用小模型做分类和摘要，判断哪些材料真的需要深度处理。精加工阶段才把强模型用上，处理真正复杂的长文档和逻辑校验。三层下来，我这边整体调用成本降了大概一半，速度也快了不少。

另一个常被忽略的点是缓存。同样的输入反复处理是常态，尤其是调指令阶段。开启响应缓存后，重复输入的等待时间几乎为零。注意缓存要能手动清，否则你改了指令还在吃旧结果，会怀疑人生。

提示：批处理任务尽量放在机器空闲时段跑，并且加上并发上限。我试过同时开八个任务，结果内存吃满，全部超时重试，反而比串行还慢。并发数设成 2 到 3，稳定性最好。

6. 团队推广与数据边界：从一个人用到一群人用

个人用顺了之后，团队推广是另一回事。我参与过两次内部推广，第一次失败得很彻底，第二次才跑通，差别就在几个细节上。

失败那次的原因很典型：我把自己调好的指令一股脑丢进共享目录，附了一句"照着用就行"。结果没人用。后来复盘，问题有三个——指令里的字段名是他们不熟悉的术语；输出格式和团队现有的文档模板对不上；没人知道出错了该找谁。工具推广失败，八成不是工具的问题，是配套没做。

第二次改了三件事。第一，从团队已有的痛点切入，不推"AI 能力"，推"周报合并"这一个具体动作，跑一遍给他们看省了多少时间。第二，指令里的术语全部换成团队内部叫法，输出格式直接对齐现有的周报模板，让人拿到就能用，不用二次加工。第三，建了一个问题登记表，谁用出问题往上写，每周固定花二十分钟统一处理。这三件事做完，一个月内团队里日常使用的人从两个涨到了大半。

数据边界这块必须提前说清楚，不能等出事再补。我在推广前会明确三条：

• 哪些材料可以进：公开信息、内部非敏感材料，明确列出清单。
• 哪些绝对不能进：涉及个人身份信息、未公开的经营数据、外部合作方的保密材料，一律走本地处理或人工处理。
• 产物存在哪、谁能看：输出目录的访问权限要和原始材料保持一致，不能出现"原文有限制、产物随便看"的情况。

还有个小细节值得提：给技能加一个"干跑"模式。第一次跑新技能时只输出将要执行的动作，不真正写文件。让使用者看一眼它打算干什么，确认没问题再放开。这个模式对建立信任特别有用，比任何培训材料都管用。

技能和指令攒到一定数量后，会面临"找不到"的问题。我的解决办法很简单：统一命名规则场景-动作-版本，比如meeting-summarize-v3、table-validate-v2，再维护一份一页纸的清单，写清楚每条是干什么的、谁维护、上次更新是什么时候。清单放在团队最常看的地方，比藏在一堆文件夹里强。

最后说一个我自己的体会。这类工作台真正的门槛不在安装，也不在会不会写提示词，而在你有没有耐心把一件事拆到足够细。拆得越细，指令越稳，技能越不容易出错。我见过太多人一上来就想做一个"全自动处理所有文档"的超级技能，结果每一步都含糊，跑起来处处漏。反过来，先把"把会议纪要里的行动项抽成表格"这一件小事做扎实，后面串什么都很顺。这个顺序别搞反了。