规划项目最常见的 AI 用法，是把几份材料上传到对话框，然后让它「总结一下」或「生成一份汇报 PPT」。

这个入口看起来直接，却把最危险的一步跳过去了：材料分别是什么版本，哪些内容可以直接采用，哪些只能作为参考，哪些口径仍然冲突，AI 还没有弄清楚。

2026 年 7 月 15 日，我在绍兴某规划院开展了一场两个半小时的 WorkBuddy 实战培训。

现场没有从功能菜单讲起，而是设置了一项完整任务：一位规划项目负责人刚接手一个工作文件夹，里面有七份用途、时间和可信程度尚未理清的材料，第二天需要做阶段汇报。

这是为培训现场准备的实操工作空间，不是院方在研项目材料。

这项实操的第一句要求不是「帮我做 PPT」，而是先不要写汇报，也不要移动文件。

这条限制决定了后面的工作顺序：先理解证据，再整理项目；先暴露冲突，再形成结论；先让人确认方向，再让 Agent 执行高成本任务。

下面按这条任务链，拆开 WorkBuddy 接手规划项目的六个执行环节，最后再用一张验收表检查结果。

## 一、第一项任务是材料审读，不是内容生成

真实项目里的文件通常来自不同时间和角色。旧版 PPT、会议纪要、Excel 台账、Word 报告和补充说明可能同时存在，同一个指标也可能因为统计时间或统计口径不同而出现多个数字。

如果第一步就让 Agent 写汇报，它会倾向于从现有文本中选择一种说法，并把内容组织得完整、流畅。格式上的完整，反而可能掩盖证据上的冲突。

更稳的做法，是先把任务限定为「只读审计」。提示词可以这样组织：

```text
我刚接手一个规划项目，明天需要做阶段汇报。
工作空间里有多份不同格式、不同时间的材料。

先不要写汇报，也不要移动、重命名或覆盖任何文件。
请逐份读取材料，并为每份材料记录：
1. 文件主要内容；
2. 大致时间与版本；
3. 在本次汇报中的用途；
4. 可以直接使用、只能参考，还是必须进一步确认；
5. 与其他材料存在的冲突或缺口。

最后输出材料清单、冲突清单、缺失信息和目录整理建议。
等我确认后，再执行任何文件操作。
```

这段任务里有三个技术边界。

第一，把读取与改写分开。Agent 可以先列目录、解析文件和做对照，但不能一边判断一边改变原始材料。

第二，给材料设置可信等级。「直接使用」「只能参考」「需要确认」比笼统的「重要」或「不重要」更接近项目决策。

第三，把文件操作放到人工检查点之后。整理建议可以自动生成，移动、改名和覆盖则要等人确认。

在公开案例中，WorkBuddy 遇到 Word、PPT、Excel 等文件时，先借助脚本提取可读取的文本，再完成跨文件比较。它还识别出两份材料对同一指标的记录不一致：一份旧 PPT 记录 9 处，另一份 Excel 列出 12 处。

Agent 能做的是把差异暴露出来。多出的 3 处究竟是新增点位、统计时间不同，还是口径发生变化，必须由项目人员继续核验。

![WorkBuddy 主动解析不同格式文件](https://developer.qcloudimg.com/http-save/yehe-11679100/e8779170887c891fbcda9f00930f722b.png)

![材料审读结果与口径冲突清单](https://developer.qcloudimg.com/http-save/yehe-11679100/c3241a1b543685507698ac3f7be4e794.png)

## 二、目录不是收纳工具，而是项目的数据管道

材料审读完成后，下一步不是马上搭一套复杂的项目管理系统。公开案例只设置了四个区域：

```text
01_输入材料
02_研究分析
03_内容底稿
04_交付成果
```

`01_输入材料` 保存收到的原始文件，只读、不覆盖。这里是证据起点。

`02_研究分析` 保存联网调研、数据处理、对照表和中间结论。这里允许迭代，但每项关键判断要能回到来源。

`03_内容底稿` 保存经过人工确认的统一口径。PPT、PDF、Word 报告等下游成果优先从这里读取，避免每次重新解释一遍项目事实。

`04_交付成果` 保存给人查看和使用的正式文件，版本号、日期和用途需要清楚。

这四层结构同时解决两个问题。

对人来说，它把原始证据、研究过程、统一口径和最终交付分开。新成员进入项目时，不必依靠某个人的记忆寻找「最终版」。

对 Agent 来说，目录名直接提供检索线索。它知道哪些文件只能读取，哪些内容可以继续分析，哪些底稿代表当前确认口径，哪些文件属于对外交付。

这里最重要的规则不是目录名称，而是不可逆边界：原始材料不覆盖，未经确认的研究判断不直接进入内容底稿和交付成果，交付成果也不反向充当原始证据。

![规划项目四层文件夹结构](https://developer.qcloudimg.com/http-save/yehe-11679100/a662486c5d475684fe5395fcc5adbad7.png)

## 三、项目上下文要把稳定规则和动态状态分开

一次对话可以记住前面发生了什么，但规划项目通常会持续数周甚至数月。新开对话、切换人员或间隔一段时间后，聊天记录无法可靠承担项目状态。

公开案例把项目上下文拆成两类文件。

第一类是稳定规则。在当时版本的 WorkBuddy 中，案例使用项目根目录的 `CODEBUDDY.md` 记录：项目用途、目录职责、原始材料只读、事实分为已确认和待确认、重要文件操作前先询问，以及关键任务完成后更新项目状态。

第二类是动态状态。案例使用 `00_项目总览.md` 记录：当前目标与阶段、已经确认的事实、现有成果及路径、待确认问题、风险和下一步动作。

这两类信息不能混在一起。

项目规则相对稳定，不应该因为某次汇报完成就被改写。项目状态持续变化，也不应该被固化进长期系统指令。

可以给 WorkBuddy 这样的任务：

```text
请根据刚才的材料审读结果，建立项目的长期上下文。

先检查项目规则文件，写清项目用途、目录职责和操作边界：
- 原始材料只读，不覆盖；
- 研究分析、内容底稿和交付成果进入对应目录；
- 事实必须区分「已确认」和「待确认」；
- 移动、删除文件或改变重要结论前先询问；
- 完成关键任务后更新项目总览。

再创建项目总览，记录当前目标、已确认事实、现有成果、
待确认事项、主要风险和下一步动作。
```

完成之后，不要只检查文件是否存在。应该新开一个空白对话，让 Agent 说明项目目标、当前进度、未决问题和下一步动作。

如果它能主动读取项目文件，并且没有把待确认内容说成正式结论，这套上下文才算开始发挥作用。

发布前需要复核一个版本问题：`CODEBUDDY.md`、初始化命令和项目记忆入口可能随 WorkBuddy 更新而变化。文章可以保留公开案例的真实做法，但界面和命名要以发布当日版本为准。

![项目规则与项目总览的分工](https://developer.qcloudimg.com/http-save/yehe-11679100/73e3347019cf66a131dd4e1c6f2b887f.png)

![新对话主动读取项目状态](https://developer.qcloudimg.com/http-save/yehe-11679100/774ed2eb148fa5faa3a0add26cbfb4ee.png)

## 四、DeepResearch 先确认研究计划，再启动并行执行

规划研究很适合使用 DeepResearch，因为问题通常涉及政策、同类地区案例、空间方案、实施机制和数据证据，单次搜索很难覆盖完整。

但 DeepResearch 不是把问题写得越大越好。范围过宽会让研究方向发散，不同研究任务重复检索，最后产生一份来源很多、却很难进入项目决策的报告。

公开案例在正式研究前增加了一次人工检查点：

```text
请先结合项目总览和现有材料，提出本轮研究计划。
计划至少包含：
1. 本轮准备回答的核心问题；
2. 拆分后的研究方向；
3. 每个方向优先查找的来源类型；
4. 预期交付物和文件位置；
5. 哪些结论必须由项目人员确认。

先展示计划，不要立即开始调研。
等我确认研究范围和来源边界后，再启动执行。
```

现场计划形成后，人先核对四个研究方向，确认案例范围是限定浙江，还是扩展到长三角，并检查输出是否能服务后续汇报。确认之后，主 Agent 才把不同方向交给多个研究任务并行推进。

这一步的重点不是追求 Subagent 数量，而是让每个研究单元拥有清楚的问题、来源边界和产出位置。

如果某个研究单元只负责政策，它就应该优先处理政府部门、法规和标准文件；如果负责同类城市案例，就需要记录城市条件、实施时间、适用边界和原始来源。研究结果分别写入 `02_研究分析`，再由主 Agent 去重、交叉核验和汇总。

模型是否会稳定按计划启动并行研究，取决于当前版本、模型能力和任务配置。提交提示词后，人不能退出流程，仍要检查实际执行路径、来源和结论边界。

![DeepResearch 执行前的人工检查点](https://developer.qcloudimg.com/http-save/yehe-11679100/e5e30d09c60a2e8c3f6f152f0bc8ab26.png)

![确认四个研究方向后并行执行](https://developer.qcloudimg.com/http-save/yehe-11679100/d84334bf29e7504c2f6022b35a97a485.png)

## 五、先跑通一次，再把稳定路径做成 Skill

研究报告完成后，规划单位通常还需要把 Markdown 或文本底稿转换为固定格式的 Word 文档。标题字号、字体、表格样式、页眉页脚和页面设置都可能有统一要求。

如果这些规则每次都靠一段临时提示词重新说明，结果很难稳定，也不方便团队复用。

公开案例先用文档生成能力完成一次真实转换，再打开 Word 文件逐项核对标题字号、正文字体和表格样式。确认路径跑通后，才调用 Skill Creator，把输入要求、处理步骤、模板规则、脚本和验收标准固化为一个 Skill。

创建 Skill 时可以这样描述：

```text
刚才的 Word 文档已经按单位模板完成并通过逐项核对。
请使用 Skill Creator，把这条成功路径固化为一个文档生成 Skill。

它需要把符合已确认输入条件和元素范围的 Markdown 报告，转换为固定格式的 Word 文档。
正式创建前，请先通过提问与我确认：
- 页面设置、标题层级与正文字体；
- 表格样式、页眉页脚和编号规则；
- 需要支持的 Markdown 元素；
- 输入、输出目录和文件命名；
- 生成后的自动检查与人工验收项。
```

Skill 创建完成，不代表它已经可靠。

公开案例又换了一份 Markdown 报告，在新对话中重新调用该 Skill，并再次检查输出格式。这个复跑动作很重要：它验证的是规则能否迁移到第二份输入，而不是脚本只对第一份文件有效。

适合固化为 Skill 的任务通常满足三个条件：反复发生，关键步骤相对稳定，结果可以明确验收。

顺序也不能反。先在真实输入上跑通，记录失败和修正，再提炼最短成功路径。没有完成过的流程，直接写成 Skill，只是在把想象中的方法固化下来。

![Markdown 报告转换为 Word 文档](https://developer.qcloudimg.com/http-save/yehe-11679100/cf2de5c19fbc160514df1618a3ddafd0.png)

![使用 Skill Creator 固化已验证路径](https://developer.qcloudimg.com/http-save/yehe-11679100/fc4c0a83f145a5eb1ceff5c73ccfcfd5.png)

![在新对话中用第二份输入复跑 Skill](https://developer.qcloudimg.com/http-save/yehe-11679100/7bfc3c8693008d1d68a2b121efa8ab49.png)

## 六、自动化只负责发现线索，不自动改写项目事实

规划行业还有一类高频任务：持续追踪自然资源部门、地方主管部门发布的新政策、规程和典型案例。

这类任务适合自动化，因为频率稳定、来源范围可以限定、输出格式也容易验收。但自动化不能获得修改项目事实的权限。

公开案例配置了一项规划政策日报：每天检查过去 24 小时的公开信息，最多保留 5 条，记录来源，并说明它与当前项目可能存在的关系。

同时又增加了三条边界：日报只作为研究线索；不自动修改项目总览；不把新信息直接写成项目结论。发现重要变化时，只生成一个值得继续研究的问题，等待人决定是否启动 DeepResearch。

这套权限划分可以概括为：

```text
自动化发现变化
→ Agent 形成带来源的研究线索
→ 人判断是否值得研究
→ DeepResearch 补充证据
→ 人确认后进入项目总览和内容底稿
```

自动化适合扩大感知范围，不适合绕过确认机制。政策是否适用于当前项目，数据口径是否发生变化，哪些内容可以成为正式依据，仍然由项目负责人承担判断责任。

![规划政策日报自动化及其权限边界](https://developer.qcloudimg.com/http-save/yehe-11679100/5c2686773a123c7046d6e749248afda5.png)

## 七、用一张验收表判断 Agent 是否真正接手项目

一个规划项目接入 WorkBuddy，不能用「生成了多少文件」验收。更有效的检查方式，是看项目是否建立了下面五层能力。

| 层级 | 验收问题 | 人的责任 |
| --- | --- | --- |
| 材料层 | 每份材料的版本、用途、可信等级和冲突是否清楚 | 确认来源与口径 |
| 结构层 | 原始证据、研究过程、统一底稿和交付成果是否分开 | 决定目录规则与权限 |
| 状态层 | 新对话能否读取当前目标、进度、风险和待确认事项 | 维护正式项目状态 |
| 研究层 | 高成本研究是否先确认问题、范围、来源和产出 | 审核研究计划与关键结论 |
| 复用层 | 已跑通流程能否在新输入上通过同一套验收 | 决定哪些经验值得固化 |

公开培训现场没有把原计划中的两轮反馈、独立 Review、PPT 和 PDF 二次装配全部跑完。保留这个事实很重要，因为它说明这套方法不是一场演示里「所有功能都成功了一遍」。

现场真正跑通并公开记录的，是从材料审读、目录整理、项目上下文、研究计划确认，到文档 Skill 创建与复跑的主链路。

WorkBuddy 可以承担读取、搜索、整理、生成和迭代。规划人员仍然负责项目目标、材料可信度、统计口径、专业判断和最终交付。

Agent 真正接手项目，不是人把责任交出去，而是让证据可以追溯、状态能够续上、执行前有检查点、成功路径可以复跑。

---

本文基于作者已公开发布的规划行业实战案例重新组织，针对腾讯云开发者社区读者改写。完整公开案例：[从会问 AI，到让 Agent 接手一个规划项目](https://zhijian-ai.cn/articles/workbuddy-shaoxing-planning-agent/)

规划项目最常见的 AI 用法，是把几份材料上传到对话框，然后让它「总结一下」或「生成一份汇报 PPT」。

WorkBuddy 规划行业实战：让 Agent 从 7 份材料接手一个项目

规划项目往往不是缺少材料，而是材料版本、可信程度、项目状态和研究口径没有进入同一套上下文。本文拆解如何让 WorkBuddy 从七份材料开始，完成材料审读、冲突识别、项目状态维护、DeepResearch 计划确认和文档 Skill 复用。

创始人

人工智能

开发工具

职业发展

规划项目AI应用核心在于先审读材料、建立目录与项目上下文，再执行研究、生成与自动化。通过材料可信分级、人工检查点及Skill固化，确保证据可追溯、状态可续接，最终以五层验收表判断Agent是否真正接手项目。

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

WorkBuddy 规划行业实战：让 Agent 从 7 份材料接手一个项目-腾讯云开发者社区-腾讯云

WorkBuddy 规划行业实战：让 Agent 从 7 份材料接手一个项目

WorkBuddy 规划行业实战：让 Agent 从 7 份材料接手一个项目

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐