夜雨聆风项目概览
前两篇聊的是——Word/PDF 格式转换、PDF 编辑，把基础功能做出来。但这个项目还有第二个、也是我更看重的目的：不止于做一个办公工具，而是让工具真正"聪明"起来、能替你动手干活。这一篇，就聊这个——也是整个项目的灵魂。
一、项目需求
现在的 AI 助手，你让它"帮我把这段话改正式一点"，它会很热情地给你一段改好的文字。然后呢？然后你得自己复制、粘贴、替换回去。它是个很会说的顾问，却不是个能动手的助手。
真正的办公场景里，我们要的往往是后者：
"把第三段改正式一点" —— 它就该直接改好第三段，而不是让我自己动手。"在表格 B 列算一下总和填到 B10" —— 它就该直接把结果填进去。
所以这个项目要解决的，就是让 AI 从"会说"进化到"会做"：用户用大白话下指令，AI 直接操控文档和表格，把活干了。下面是它现在能替你做的痛点功能一览：
类别 | 以前你得手动做 | 现在一句话，AI 直接做 |
文档 | 翻半天才找到某段话 | 按关键词直接定位段落 |
文档 | 润色 / 改写 / 纠错，自己复制粘贴替换 | 直接替换某段文字 |
文档 | 手动在某处补一段内容 | 在指定位置插入新内容 |
文档 | 手动调标题、加粗、对齐 | 直接把某段设成标题 / 加粗 / 对齐 |
表格 | 一行行看数据 | 直接读取表格数据 |
表格 | 手拉公式算总和 | 直接写入公式、填好结果 |
表格 | 一块区域重复填 | 批量填充一片区域 |
表格 | 逐个设格式、加行 | 直接设格式、追加一行 |
你只管用大白话说，它来动手。而且——它动手前，一定先给你看"将要怎么改"，你点头了才真的改。
二、项目功能
下面演示两个最核心的痛点场景（文字版，操作前后对比）：
演示 1 · 文档操控：把一段话改正式
• 输入：在对话框输入"把第一段润色得更正式"。
• AI 的操作：先读文档定位到第一段，再弹出一张预览卡片——"将把第 0 段替换为：××××"。
• 输出：你点"确认"，文档里那段文字真的变了。不用复制、不用粘贴。
演示 2 · 表格操控：算总和填结果
• 输入：在对话框输入"在表格 B 列算一下总和，填到 B10"。
• AI 的操作：先读表格拿到 B 列数据，算好总和，弹出预览——"将把 B10 写入：××××"。
• 输出：你点"确认"，B10 单元格里出现了结果。
注意这两步里那张"预览卡片"——AI 动手前，一定先让你看清它要改什么，你同意才落地。这是整个设计里最要命的一环，下面细说为什么。
三、藏在功能背后的思维链(重点)
这里先提个观点：决定 AI 在你产品里表现上限的，往往不是模型本身，而是你"怎么和它对话"。
同一个大模型，你给它一份含糊的指令，它就胡乱发挥；你给它一份界定清晰、职责分明的"契约"，它就稳定听话。这份契约，我把它叫"文档思维链"——本质上等同于工程架构，你设计的不是代码，而是"人、AI、软件"三方如何协作的规则。
它由三部分组成，每一部分都是一个关键决策。
3.1 架构思维：把 AI 能做的事，用"读 / 写"一刀切开
我给 AI 定义了一份"工具清单"（读文档、查段落、替换、插入、改格式；表格的读、写、格式化……）。每个工具都写清：叫什么、干什么、要什么参数。
最关键的一个决策是：把工具明确分成"读"和"写"两类。
• 读类（读文档、查段落）：AI 可以自动执行，拿到结果继续思考。
• 写类（替换、插入、改格式）：AI 不能直接落地，必须先给用户看、用户确认了才改。
为什么这么分？因为"读"是无害的（看看而已），"写"是会改变文档、不可逆的。让 AI 自由地"看"，但对"动手"保持敬畏——这就用一条清晰的分界线，调和了"AI 自主性"和"用户控制权"这对矛盾。
3.2 执行规则：用人话把"游戏规则"讲给 AI 听
光有工具清单不够，还得告诉 AI 怎么用。这就是"系统提示词"——给 AI 的一份岗前说明书。其中最重要的一条是：
"改文档前，先用读工具了解现状。需要修改时调用写工具——写操作不会立刻生效，会先展示给用户确认，用户同意后才真正改动。所以你不必反复向用户确认，直接调用即可。"
这句话看着平常，却解决了一个大问题：如果不这么说，AI 会变得畏手畏脚——每改一处都反问"我可以改吗？你确定吗？"，啰嗦到没法用。把"确认"这件事的责任从 AI 手里接管过来（交给系统的预览机制），AI 就能放心大胆地干活。
真实任务往往不是一步到位的。比如"把讲钱的那段改委婉些"，AI 得先读文档找到那段，再想怎么改，最后写回去。这就需要一套"多轮对话协议"：AI 说"我要读文档" → 系统执行、结果回填给它→ AI 看到内容后说"我要改第 3 段" → 系统预览、你确认、执行、再回填 → AI 确认改完，给你一句总结。读→想→做，循环往复，直到任务完成。
这套协议用的是行业通用的标准格式，好处是不锁死任何一家大模型——DeepSeek、通义、智谱、Kimi，谁支持这套标准就能直接接上用，你可以自由换。
3.3 文档的进化：从"容易失控"到"稳定可控"
给了 AI 动手的能力，就必须防它捅娄子。下面这张表，是踩坑过程中"文档从出错版进化到稳定版"的真实记录——每一行，都是一个坑变成一条规则的过程：
踩过的坑（出错版） | 文档修订（稳定版） | 优化思路 |
AI 每改一处都反问"可以吗？"，啰嗦到没法用 | 提示词写明"写操作会先展示确认，直接调用即可" | 把确认责任从 AI 转给系统 |
AI 可能改了又改、停不下来，烧算力还搞乱文档 | 加有界循环：调用工具的轮数设硬上限，到顶自动停 | 事前设界，防死循环 |
AI 要改"第 5 段"，但文档只有 3 段，直接崩 | 加参数校验，回一句"第 5 段越界（文档共 3 段）" | 让 AI 优雅失败、自己重试 |
一次改好几处，前面插入导致后面段落位置全变 | 写操作从后往前改 | 想清楚执行顺序，避开连锁错位 |
我认为文档修订是文档驱动开发中很重要的一步，贯穿在与大模型交互的整个过程，直到项目结束；而如何使文档的修订有效，并总结出一定的经验，需要较多项目经验的累积。上面的几条，是从此项目中列出的几条文档修订的经验，供参考。
四、下一步：还要做什么
第一、这套"文档思维链"跑通了，但离"省心"还有距离，接下来会继续完善，下面列出两处完善方向：
1. 跨文档批量操作：现在 AI 一次操控一个文档。下一步让它同时读写多个文档，比如"把这三份文档的标题统一成某某"。办公里批量处理是常态，单文档限制太大了。
2. diff 式预览：现在写操作的预览是文字描述。下一步做成逐字对比的高亮预览（旧文字划掉、新文字标绿），让"确认"这道闸更直观、更可靠。
第二、后续项目初步考虑会把相关文档修订经验作为一个重点模块去积累去分享。
五、文档分享
完整文档已整理好，点左下角【阅读原文】即可查看。（此文档参考使用时，请先阅读免责声明）
