从7月初开始，作者陆续面试了一些AI加全栈方向的岗位，以及少量垂直APP开发也就是纯Flutter岗位。但谈下来的结果，只有一家愿意开到平薪，还有一家低于目前的工资。这让他停下脚步，思考下一个职业机遇的增长点到底在哪里。

他打开招聘软件重新扫了一遍岗位，发现一个明显趋势：中小型企业对产品加开发的复合型人才是有热度的。但这些岗位通常以产品为主、技术为辅，和他设想中主要做开发的方向有明显冲突。于是他又陷入了迷茫。

但这个冲突反而逼着他正视一个一直逃避的问题。他过去总觉得产品岗需要的沟通和共情能力他不擅长，也不屑于去学。但如今市场摆在那里。他回头认真想了一下，为什么不擅长也不愿意做产品侧的事情？想深了之后发现，根子不在能力，在心态。

之前在博客里提到过厌蠢。经过这几年，他觉得厌蠢这个事情指向的是更加深层的心理状态——傲慢。因为人们很容易把看得清楚当成一种资格感。尤其是靠自己长期单兵作战、习得性无助、凡事靠自己解决的人，比周围的人多懂一点、走快了一步，就很容易产生一种道不明的优越感：觉得同事做事低效，觉得家里人思想落后，和周边的人沟通全是烦躁和不耐烦。

但你会发现，厌蠢这件事只会让自己觉得爽，它没办法转化成真正的生产力。真正解决问题不是你能判断谁对谁错，而是你能在认知不对等的情况下完成一次有效的传递。说白了就三件事：第一，你能不能把复杂的东西拆到一个普通人也能听懂的程度；第二，你能不能把模糊的需求翻译成具体的可执行的步骤；第三，你能不能在别人没表达清晰的时候说出对方真正的痛点在哪里。

所以作者越来越觉得，厌蠢很多时候不是你比别人高级，而是你没有意愿也没有能力进入到对方的处境，去帮助他，去理解他。

当然，他也不是提倡无底线包容所有低效。但如果你想在职场上让企业为你的能力买单，你就不能只站在自己的那层认知里去俯瞰别人，这个别人可以是同事、行业、公司。工作上需要沟通的事情，本身就是发生在不对等里面的——你比他懂，所以他才需要你；你看得比他远一点，你才有价值。如果你既想要别人需要你，又嫌弃别人不够懂你，那这件事没道理。

现在他觉得，一个人真正有本事，不是你一眼能看出谁有问题。指出问题很简单，难的是你把一个人带到有结果那里。真正需要积累的，不是你比谁厉害，而是别人和你聊完之后真的更清楚了，和你合作之后真的往前走了一步，原来他讲不明白的事你帮他讲清楚了，原来他不知道怎么下手的事你帮他拆清楚了。这种能力才是真正的沉淀。

所以后来他刻意地对其他人保持了耐心。你能容得下多少个不明白，你就能服务多少甲方。想通了这一点，再回头看那两份offer，倒不觉得是坏消息，它们只是提醒他：该换一种方式了。虽然你有大量的项目经验，也能试用很多不同的技术栈，但在AI的浪潮下，以及大量企业愿意以职责混乱换取时间，我们每个人都不能在这场浪潮中独善其身。

从 7 月初开始，陆陆续续去面了一些试，大体都是 **AI+全栈** 的方向，以及一小部分垂直的 A

最近面试和一些心理转变

这篇博客总结了一个聊天型AI Agent的文件分析模块从上传到生成结构化数据的完整链路。核心结论是：文件分析不是一步到位的OCR，而是一个分层加工的过程，每一层解决不同的问题。

作者从实际项目出发，新建了一个干净的TypeScript项目，只复刻文件分析链路，不涉及聊天和入库，便于观察每一层的输出。

整体流程为：文件上传 -> 文件解析/OCR -> 页面文字拼接 -> LLM结构化抽数 -> JSON格式校验 -> 业务数据清洗 -> 提供给Agent继续对话。

第一层：文件解析决定如何获取文字
并非所有文件都需要OCR。TXT、CSV、Word、Excel以及有文字层的PDF可以直接提取文字；图片和扫描版PDF才调用PaddleOCR。PDF提取文字时如果内嵌文字少于30个字符，会退回到OCR。本地解析优先，速度快且减少OCR识别错误。

第二层：PaddleOCR将图片变成文字
只负责读取页面上的字符，返回分页结果，包括每页的识别文本和置信度。置信度表示OCR对页面文字的把握，不表示业务字段的准确性。

第三层：拼接文字并截断
将非空页面按顺序拼接成一段纯文本，为避免模型上下文溢出，只发送前12000个字符。这一步决定了LLM看到的内容质量——OCR的错误会直接传递到LLM。

第四层：通过Prompt要求LLM返回结构化JSON
Prompt中明确字段、枚举、对象结构，并要求只输出JSON，不解释，不猜测。返回结果包含candidate数组（人物、公司、小区等）和extractedFields（姓名、身份证等）。candidate通过slots将多个字段绑定到同一实体，防止后续拼接错误。

第五层：LLM返回JSON后不能直接使用
即使开启response_format: { type: "json_object" }，模型返回的JSON结构仍可能不符合业务要求。例如字段位置错误、类型不对等。需要服务端进一步校验。

第六层：使用Zod约束数据结构
定义Zod Schema对LLM的原始输出进行safeParse。首次接入严格校验立刻发现了模型将archiveDocument放在顶层而非extractedFields内的问题。Zod只检查结构正确性，不检查内容真实性。

第七层：业务清洗弥补Zod的不足
Zod通过后还需要服务端处理：去重、转大写、移除空白/连字符、检查关系两端是否存在、防止孤立字段自动关联、避免重复候选等。最终生成normalizedInsight。

第八层：通过接口观察每一层中间结果
提供一个POST /files/analyze接口，返回pages/parsedText、llmRawText、llmRawOutput、normalizedInsight、wouldPersist等字段。调试时可以直接对照OCR文字、LLM原始输出和服务端清洗结果，快速定位问题。

总结：文件分析的每一层职能清晰
【文件解析器】决定如何拿到文字
【PaddleOCR】负责扫描件转文字
【LLM】从文字中抽取结构
【Zod】拦截错误数据结构
【业务清洗】决定数据能否真正使用

最容易产生的误解是认为LLM输出JSON就等于已经结构化。实际上它只是“模型认为的结构化数据”，必须经过服务端校验才能进入Agent。

后续章节计划：文件结果如何进入聊天上下文、用户追问时关联最近文件、以及从文件中生成安全候选池。

## 前言

最近一直在做一个聊天类型的`AI Agent`，希望用户在聊天框上传流水、征信、身份证

工作随笔

最近面试和一些心理转变

Agent 第一章：文件识别、LLM 抽数与 Zod 校验

推荐

分类目录