做政策分析最花时间的从来不是"写"，而是"读"和"整理"。我手头常见的活儿是这样的：几十份政策原文、解读文章、统计数据堆在硬盘里，格式五花八门，有PDF、有网页另存的HTML、有扫描件、有Excel表格。过去我靠肉眼一份份读完，把关键段落复制进笔记，再自己做对照表，最后才开始真正有价值的判断和写作。后来我把 Claude Code 接进了这套流程，才发现政策分析的效率天花板，比大多数人想象中高得多。这篇就聊聊我是怎么用 Claude Code 重新搭起一套政策分析工作流的，以及哪些环节真的省时间、哪些环节必须留给人来做。
1. 政策研究的时间黑洞：资料越多，产出越慢
先说说传统政策分析里最磨人的环节。很多人以为这个工作的核心是"解读政策"和"给出建议"，实际上在真正动笔之前，你得先过掉三关：
第一关是资料收集。政策研究的资料来源极其分散，正式文件是一类，官方解读是一类，行业评论是一类，统计数据又是一类。每类来源的格式都不一样，有的还能直接复制文字，有的是扫描图片，有的压根就是一张截图。把几十份甚至上百份资料从原始形态整理成"能查、能读、能引用"的统一文本，这一步通常要消耗掉一个项目三分之一的时间。
第二关是精读与摘要。研究一个课题，不是每份资料都要从头读到尾，但你又不能不看就判断哪些内容重要。一篇三十页的行业规划，核心可能就三页；一篇八千字的解读文章，关键信息可能就是两个时间节点。人的注意力是有限的，连续精读五六份长文件之后，前面读过的内容就开始在脑子里模糊，得翻回来重看。这个阶段特别消耗意志力，也是整个流程中最早让人产生"不想干了"念头的地方。
第三关是对比与溯源。政策分析最值钱的部分往往不是单篇理解，而是"多篇之间的差异"——上一版文件和这一版文件差在哪，这个部门的要求和那个部门的表述是否冲突，不同年份的政策对同一对象的约束发生了哪些变化。做这类逐条对比，意味着你要在多个文件之间来回切换、反复定位页码，手工整理成矩阵。等材料多了，还要给每条结论标注出处，方便后续验证和写作引用。这部分工作的琐碎程度，几乎能把任何一个研究者的耐心耗尽。
我自己的体感是：一个中等难度的课题，如果涉及二十份以上的资料，旧工作流至少需要一周，而且其中真正花在"思考"上的时间不到三分之一，剩下大部分都被"找、读、抄、对"吃掉了。
所以当时我给自己定了一个目标：把"文本初筛、结构整理、差异罗列"这些机械化劳动尽量交给工具，把自己从重复阅读里解放出来，把省下的时间拿去读真正重要的原文，做真正需要判断的结论。Claude Code 就是我试下来比较顺手的那套工具。
2. 换个思路：让一个能碰本地文件的 AI 代理替我做初筛
2.1 网页版对话为什么不够用
在决定引入 Claude Code 之前，我当然也试过更省力的路子，比如把几十页的政策文件粘贴进网页版 AI 对话框。一开始觉得挺好用，要个摘要、问个差异都能答上来，但用得多了就发现，网页版对话模式在研究场景里有几个绕不开的短板。
第一个问题是"每次都要重新解释背景"。网页对话没有项目概念，每开一个新对话都得重新告诉它"我在研究什么、文件是什么背景、输出格式要怎样"，上下文稍微长一点，前面交代过的规则它就开始忘。第二个问题是它读不了本地文件。PDF、扫描件、表格这些资料我没法直接丢给它，得先转成文本再复制粘贴，而政策文件动辄几十页，粘贴一段就占掉大量上下文，根本没法批量处理。第三个问题是它不产生"文件"——分析结果都在对话框里滚动，没法直接变成项目目录里的结构化产出，后续做矩阵、做引用、做报告又得人工搬运一遍。
简单说，网页版对话适合"问一个问题、拿一个答案"的场景，但不适合"处理一批文件、产出一套研究成果"的场景。
2.2 Claude Code 在自己的工作区里做什么
Claude Code 不太一样。它的工作方式是直接跑在本地项目目录里，能读取整个工作区的文件、能自己编辑文件、能执行命令行工具，还能通过配置文件记住你的研究约定。如果说网页版对话是"一个知识很丰富但只能隔着窗口聊天的实习生"，那 Claude Code 更像是"一个坐在你电脑前、能自己翻资料柜、做笔记、按你的格式整理成稿的实习生"。
具体到政策分析场景，它带来的改变有三个层面。
第一是"能碰到原始资料了"。我可以把整个研究目录交给它，让它直接读取raw文件夹里的文本，而不是靠人工复制粘贴。第二是"能批量加工了"。读完一份，它可以按固定模板写摘要；读完二十份，它可以统一生成对比矩阵。整个流程是它主动规划、主动执行、再回来跟我确认，而不是我一步一步手把手教。第三是"能记住这个项目的规矩了"。我可以通过CLAUDE.md把研究约定固化下来，比如输出格式、引用规则、禁止臆造哪些内容，之后每一次对话它都会主动遵守。
2.3 这个方案适合哪类研究任务
当然，Claude Code 也不是万能的。我个人的体会是，它最适合的是"文本密集、规则清晰、产出格式固定"的研究任务。比如政策条文梳理、多版本差异对比、不同主体观点聚类、基于文本的要素提取，这些任务的核心是"从大量文本里找出信息并整理成结构"，正好是 AI 代理的舒适区。
但如果是"基于不完整信息判断政策走向""权衡各方利益给出倾向性建议"这类需要大量隐性知识和现实经验的环节，我的做法是坚决留给人来做。把 AI 当工具而不是当替身，工具负责把事实和结构摆到桌面上，判断和取舍由人来定。这个分工思路贯穿了后面整套流程。
3. 落地一套政策分析流水线：目录、规则和批量处理
理论说完，说说具体怎么做。我以"某行业监管框架三年演变"这个小课题为例，把整个流程拆开讲。这套东西不大，但完整走下来，基本能覆盖多数政策研究项目的通用动作。
3.1 目录设计：资料的物理归档先于 AI 处理
很多人一开始就急着让 AI 读文件，结果目录乱成一团，AI 反而找不到该看哪个文件。我的建议是，动手之前先花二十分钟把目录结构定下来。政策研究项目通常可以分成五层：
policy_research/ ├── raw/ # 原始资料：PDF、HTML、DOCX ├── text/ # 转换后的纯文本 / Markdown ├── notes/ # 单篇摘要和结构化要点 ├── matrix/ # 对比矩阵、时间线 └── drafts/ # 报告草稿、引用清单这个结构的好处是：raw是只读的原始存档，任何时候都能回头核对原文；text是给 AI 读的中间产物，格式统一；notes和matrix是 AI 加工的成果，也是人后续核查的主要对象；drafts才是最终报告的地盘。文件和中间产物分得清清楚楚，AI 不会把分析结果写进原始文件夹，我也不会在找资料时被一堆摘要文件干扰。
3.2 统一文本格式：让所有资料变成 AI 能读的纯文本
目录建好之后，先把raw里的资料统一转成纯文本。这一步很枯燥，但非常重要。AI 读的是文本，不是 PDF 的排版，不定要先做格式转换。我常用的命令是：
mkdir -p text # PDF 转文本，保留版面顺序 for f in raw/*.pdf; do pdftotext -layout "$f" "text/$(basename "$f" .pdf).txt" done # DOCX 转文本 libreoffice --headless --convert-to txt --outdir text raw/*.docx转换完不是直接开跑，我会先抽查几份结果。重点看两个地方：文件是否为空，扫描件是不是转出来一堆乱码。如果遇到扫描版 PDF，pdftotext基本无能为力，得先过一遍 OCR，再进text目录。这一步偷懒的话，后面 AI 分析的一定是一堆噪音。
注意：转换后的文本一定要和原始文件保持同名，方便后续引用追溯。我见过有人转完文本改成
1.txt、2.txt，后面想查出处完全对不上号，等于白干。
3.3 用 CLAUDE.md 把研究习惯固化下来
Claude Code 支持在项目根目录放一个CLAUDE.md，每次对话它都会主动读取。这个文件相当于项目的"员工手册"，把固定规则写进去，就不用每次对话反复叮嘱了。我建的这个政策项目，CLAUDE.md大致长这样：
# 政策研究项目约定 你在帮助我完成政策文本分析任务。 ## 工作原则 - 所有结论必须基于我提供的文本，禁止补充外部知识。 - 原文没有提到的信息，一律标注"未提及"，不要自行推断。 - 关键结论后必须附出处，格式为：【文件名>段落编号>原文摘录】。 ## 输出规范 - 单篇摘要模板：文件背景、核心条款、受影响主体、时间节点、潜在影响。 - 对比矩阵使用 Markdown 表格。 - 禁止使用"更加""显然""一定"等模糊推断词。 ## 文件约定 - raw/ 存放原始文件，不要修改。 - text/ 存放转换后的纯文本。 - notes/ 存放单篇摘要。 - matrix/ 存放对比结果和引用清单。写完之后，你会发现后面每次让 Claude Code 干活，它都默认遵循这套规范，不用再重复交代。这个文件本身也是项目资产，换了机器、换了个助手，规则还能继续用。
3.4 单篇摘要与结构化输出：批量加工的起点
准备工作做完，才开始真正的核心流程。我的方法是：一次只让它处理一篇，产出固定格式的摘要，存到notes/目录。等二十篇都处理完，再进入对比阶段。
给它的指令大致是：
阅读 text/ 目录下的《某行业监管框架意见稿.txt》，按 CLAUDE.md 规定的模板输出摘要。 要求： 1. 核心条款 3~8 条，每条一句话，必须包含具体数值、日期。 2. 不要用你自己的话改写原文，只做忠实提炼。 3. 将结果保存到 notes/ 目录，文件名为 原文件名加 _summary.md。这里有个关键决策：为什么一次只让它处理一篇，而不是一次性丢二十份？因为单篇处理的上下文空间很充裕，它能把注意力集中在文本细节上，输出的摘要质量明显更高。一次性丢太多文件，前期还正常，后期它会开始丢维度、漏条款，甚至把文件之间的内容搞混。宁可多做几次，也要保证质量稳定。
处理完一批，随机抽两三篇人工核对，重点看：核心条款是否抓全、数值日期是否准确、有没有"根据常识补充"出来的内容。核对无误再继续下一批。这个抽查步骤不省，一旦后面矩阵建立在这批摘要上，源头出错会成倍放大。
3.5 自动生成对比矩阵和时间线：把人类最磨人的环节交出去
单篇摘要全部生成后，让 Claude Code 基于notes/目录里的结构化作笔记，生成对比矩阵。还是那个某行业监管框架的课题，我会给它一个对比维度清单，比如：申报门槛、审批时限、适用范围、违规处罚力度、配套激励措施。
Claude Code 会输出类似这样的表格：
| 维度 | 一版意见稿 | 正式稿 | 差异说明 |
|---|---|---|---|
| 申报门槛 | 年营收不低于5000万 | 未设定营收门槛 | 正式稿放宽准入条件 |
| 审批时限 | 60个工作日 | 45个工作日 | 压缩了15个工作日 |
| 适用范围 | 仅限本行业企业 | 包含上下游配套企业 | 覆盖面扩大 |
同时，我还会让它生成一条政策演变时间线，把每个关键节点的发布、修订、废止信息按时间顺序排列。这些工作在过去需要我打开多个文件、滚动翻阅、手工对齐，现在 AI 能在几分钟内把初稿拉出来，而我要做的是逐条核对差异是否属实。
4. 给 AI 分析装上"防幻觉"护栏：事实核查与证据链
做技术方案的时候，AI "幻觉"听起来像个抽象风险，但在政策分析里，它表现为非常具体、非常有破坏力的问题：把"拟建立"写成"已建立"，把"征求意见稿"当成"正式实施"，把 A 文件的时间安到 B 文件身上。这种错误一旦混进报告，轻则误导判断，重则让整个研究失去可信度。
所以我在整个流水线里加了三层核查机制。
4.1 来源层：要求每条结论都带出处
第一步是在生成摘要和矩阵的提示词里，强制要求带来源引用。规则写进CLAUDE.md：每条关键结论后面必须附出处，格式为【文件名>段落编号>原文摘录】。有了这个要求，AI 输出的每一条结论都能反查到原始文本，核查效率高了很多。
如果某些内容是 AI 基于模糊记忆推断出来的，它必须在标注里写"依据不足，无法溯源"。这条规则非常关键，它逼着 AI 区分"文本里明确写了什么"和"我自己猜的什么"。我宁要一条标注了"无法溯源"的真话，也不要一段编得顺溜的假结论。
4.2 文本层：事实提取和观点判断分开做
另一个特别有效的做法是：把"引用原文"和"文章写作"彻底拆成两个任务。前者只允许它从文本里摘原句、列条款，一个字的判断都不加；后者才允许它基于摘录做分析。两件事混在一起，模型很容易顺手就把原文"改良"了。分开了之后，引用摘录部分是严格的"事实流水线"，我可以放心抽查；写作部分它再怎么发挥，也不会污染原始材料层。
4.3 人工层：抽查的比例和节奏要有讲究
不管 AI 做得多好，我的原则是：外部可交付物一定要有人工复核。具体做法是在关键节点抽查百分之二十左右的产出。以二十份资料为例，摘要阶段抽查五份，重点核对数值和日期；矩阵阶段比对八成以上条目，确保每一条差异都能在原文中定位到；最终报告成稿之前，所有引用原文的关键句要全部人工扫一遍。
这个核查节奏得益于前面的目录设计——原文在raw，转写在text，摘要在notes，矩阵在matrix，任何一条引用都能顺着路径在几分钟内找到源头。没有中间产物的分层管理，人工核查的成本会成倍上升。
5. 实操中踩过的坑和对应解法
流程不可能一次跑通。我在这套体系上线的前两周里踩了不少坑，挑几个有代表性的说说，给准备上手的人提前打个预防针。
5.1 上下文塞满导致的"降智"现象
第一次批量处理时，我试图一次让 Claude Code 读完十份文件再统一出摘要。前几份非常正常，到第七八份开始，输出开始出现明显问题：条款越来越概括、数值开始模糊，甚至把前面的文件内容混进当前文件。
原因很清楚：单次对话的上下文是有限的，塞得越多，模型在长尾部分的注意力就越差。解决办法就是前面说的，改成"单篇处理、结果落盘、再开新对话"。每次处理完一篇，摘要已经写进notes/，对话的历史使命完成，直接关掉。下一次处理下一篇，所有规则靠CLAUDE.md兜底，完全不依赖之前的对话记忆。这样每篇处理的上下文都干净、充裕，输出质量稳定。
注意：不要为了省事把大任务一次性交给它。宁可多开几次对话，也要保证每次任务范围小而明确。
5.2 输出格式悄悄漂移
第二个坑是格式漂移。刚开始跑的时候，我在提示词里要求摘要输出 JSON 格式，跑了几批之后发现，某些文件的输出变成了 Markdown 列表，字段名也从approval_time变成了time_approved，等到拼接对比矩阵时数据对不上。
后来查下来，原因是我中途改了提示词里的一句话，模型基于"最近的对话习惯"调整了输出风格，前面的模板没及时顶住。解决办法有两层：
第一层是把输出模板永远固化在CLAUDE.md，不要依赖每次提示词里的临时约定。第二层是在批量处理之后加一个格式校验脚本。比如要求 JSON 的话，就写个简单循环：
for f in notes/*.json; do jq empty "$f" || echo "Invalid JSON: $f" done任何不符合格式的文件立刻暴露。不要相信"每次都检查太麻烦"，格式漂移是长期跑批量任务一定会遇到的问题，跑一次校验脚本只要几秒钟，比事后返工划算得多。
5.3 引用张冠李戴：语气和时态陷阱
还有一个特别隐蔽的坑：AI 在总结时会把"拟建立"写成"已建立"，把"力争达到"写成"达到"。这类错误不涉及具体数值，光看单句非常难发现，但放进政策分析报告里就是重大失误。
我的对策是：在CLAUDE.md里明确要求，摘要里的动词时态必须严格沿用原文，不能做"时态推断"。同时，在处理完一批摘要后，我会让 Claude Code 单独做一个"语气核查"：把摘录中的关键动作词和原文列个对比表，我抽查几处，重点看"拟、将、力争、原则上、应当"这类的词是否被改动。
这个细节其实也是人工智能工具在处理政策文本时的老问题：模型天然倾向于"把模糊的信息变清晰"，因为这样输出更好读。但政策分析恰恰最吃文本本身的确定性，所以在规则层面堵住这个倾向，比事后肉眼排查省力得多。
6. 这套流程的边界，以及我现在的真实体会
流程搭起来之后，我明显感觉到自己的工作量分布发生了变化。过去一周的课题，现在大约一半天数被压缩成两天左右的"AI 加工 + 人工核查"，省下的时间主要花在最后一步：真正深入的判断。我需要读的原文没有变少——该看的重点段落还是会看，但"通读所有资料找重点"这件事不用再做了。
这并不代表 AI 能替代政策分析者。恰恰相反，它对人的判断力要求更高了。以前即使判断粗糙，至少花了很多时间在文本里泡着，脑子里有个模糊的印象；现在 AI 把结构化的摘要摆到你面前，你必须有能力快速判断哪些是重点、哪些有疑点、哪些差异值得深挖，再决定下一步让 AI 做什么。工具提升了生产效率，但判断的责任一点没减轻。
落到实操层面，我的建议是给准备尝试的人三条：
第一条，不要一开始就追求完美流程。先找一个小课题跑通：三个文件、一份摘要、一个矩阵。等你对 Claude Code 的输出风格和常见问题有了手感，再慢慢扩大规模。第二条，CLAUDE.md是这套体系里最重要的文件，花心思写它绝对值回票价。规则写得越清楚，后续维护成本越低。第三条，把"人机分工"想清楚再动手——哪些环节完全放手交给 AI，哪些环节坚决保留人工复核，提前划定边界，比事后补救省心得多。
我自己的体会是，政策分析正在从一个"拼阅读耐力"的行当，慢慢变成一个"拼判断质量"的行当。像 Claude Code 这样的工具未必是最终形态，但"让 AI 负责搬运和整理、让人负责判断和表达"的分工逻辑，大概率会在各种研究场景里越来越普及。早一点适应这个节奏，就早一点把精力花在真正值得花的地方。
