“体检报告”和“企业级AI”，听起来像是两个世界的东西。但在我做了十几个企业级AI落地项目之后，发现它们之间有一条非常隐蔽的通道：每一个企业级AI项目，本质上都在干同一件事——把现实世界一团乱麻的数据，封装成模型能稳定处理、业务能放心使用的Skill能力。
Skill这个词这两年很火，AI Agent、AI编程、知识库助手都在讲，但真正把它讲透的人很少。大部分团队在做的所谓Skill，其实就是一段写了就忘的Prompt，根本谈不上“封装”，更谈不上“企业级”。这篇文章我把个人体检报告当成一个最小但完整的样本，完整拆解一套我自己整理出来的Skill封装与落地心法：输入标准化、规则与模型混合推理、输出校验、可观测性设计、灰度发布，以及大量从真实项目里踩出来的坑。如果你正在做AI Agent、智能助手、知识库、自动化流程这类项目，这篇文章可以直接当作业参考。
1. 为什么拿体检报告开刀：企业级AI的真正难点在哪
1.1 体检报告就是企业数据困境的浓缩版
我先讲一个偏执的观点：凡是做AI落地做得头大的团队，八成不是死在模型不够强，而是死在数据不够干净。企业里的数据，甲方自己都说不清。合同有扫描件、PDF、Word、Excel三种来源，同一个字段在A系统叫“客户名称”，在B系统叫“party_name”，在老系统里直接叫“名称2”。你让大模型直接读这些东西，它连几成把握都没有。
体检报告把这个困境浓缩得干干净净。我手里有三份不同机构的体检报告：一份是公立三甲医院的，排版规整，数值靠右对齐；一份是商业体检中心的，每个指标一行带彩色箭头；还有一份是手机App导出PDF，表格直接错位。同一个指标“血红蛋白”，第一份写“HGB”，第二份写“血红蛋白”，第三份写“Hb”。葡萄糖有的用mmol/L，有的用mg/dL，参考范围还不一样。这就是活生生的企业数据缩影。
所以我说，做AI Skill封装，先拿体检报告练手是性价比极高的选择。它足够小，不需要复杂的业务背景，但把所有脏数据问题、字段映射问题、单位换算问题、参考标准差异问题全给你凑齐了。你在这个小场景里把流程跑通，迁移到合同审核、客服质检、设备运维、财务对账，换汤不换药。
1.2 医疗场景把“可靠性”三个字拉满
如果只是数据脏，工商管理专业的同学也能解决。体检报告真正值钱的地方在于，这是一个“不能错”的场景。
我举个例子：一个人空腹血糖参考上限是6.1 mmol/L，如果你把单位从mmol/L误读成mg/dL，等于把5.6这么正常的数值当成超标十倍来报。体检报告AI如果敢这么干，用户第二天就能找上门来。再比如，LLM（大语言模型）看着指标数据脑补出一句“建议进行冠状动脉造影”，这话医疗上极其激进，普通人看了心态直接崩掉。
可这种“不能错”的要求，企业级AI统统具备。财务数据错了，对不上账；运维告警错了，半夜三点拉人；客服回答错了，客户直接投诉。医疗场景只是把可靠性要求拉到了最严格档位，逼着你把输出校验、来源追溯、兜底机制全部做全。这套东西一旦形成肌肉记忆，你在任何企业场景里都会自动带上。
1.3 这个案例最适合谁来参考
我建议这几类人重点看：
- 正在做AI Agent、RAG（检索增强生成）应用的开发者，你缺的是一套让Agent能力可复用、可维护的封装套路。
- 做企业内部知识库和智能助手的同学，你的业务方一定会问“这个东西怎么会答错”，本章的输出校验和可观测性就是回答这些问题的底气。
- 任何想把AI能力嵌入现有业务系统的架构师，你需要知道Skill这个“能力层”应该怎么设计，才不会和业务系统强耦合。
看不懂代码细节没关系，方法论部分（第2章）独立可读；如果你带着实际项目，直接从第3章抄作业也行。
2. Skill封装的三层解耦：把“会做”变成“可复制”
很多团队做Skill失败，一上来就写Prompt，写完往Agent里一挂就完事了。结果Prompt一改，别的功能跟着崩；换个数据源，整个Skill作废。我自己的做法是强制三层解耦：输入层、推理层、输出层。每一层职责单一，边界清楚。
2.1 输入层：先让数据变成AI能读的标准化结构
输入层是所有人最容易忽略，但也是最关键的一层。原始数据不能直接进模型，就像你不会把一堆没洗的菜直接丢进炒锅。
具体到体检报告，输入层要做三件事：
第一，物理解析。PDF用工具抽文本，扫描件上OCR（光学字符识别），表格错位的用规则校正。这一步目标是拿到“机器可读的文本”，先把不可读的问题解决掉。
第二，字段映射。把“HGB”“血红蛋白”“Hb”全部归一化到标准字段code，比如HGB。这里需要一张别名表，别名表可以人工维护，也可以让LLM帮忙预标注，但最终建议人工过一遍。企业里的字段映射也一样，A系统的“客户名称”和B系统的“party_name”必须映射到统一schema（数据结构的字段定义）。
第三，数值清洗。单位要统一（mmol/L统一转成mmol/L，mg/dL则乘系数换算），参考范围要根据性别和年龄动态匹配（成年男性和老年女性的血红蛋白参考范围就是不一样），异常值（比如录入成负数）要标记。
做完这三步，得到一份干净的中间数据：
{ "report_id": "REP-2024-001", "patient": {"gender": "male", "age": 35}, "indicators": [ {"code": "HGB", "name": "血红蛋白", "value": 152, "unit": "g/L", "flag": "normal"}, {"code": "GLU", "name": "空腹血糖", "value": 6.8, "unit": "mmol/L", "flag": "high"} ], "parsed_at": "2024-11-01T10:00:00Z" }为什么非要花时间做中间结构？因为LLM并不善于处理“半文半数值”的混乱文本，给它干净结构反而更稳定，而且后续所有层都只依赖这个中间结构，PDF格式变了、OCR识别率变了，都不影响上层逻辑。这就是解耦的第一个好处。
2.2 推理层：规则引擎与模型的混合路线
输入干净了，接下来是推理。这里我有一个非常坚定的立场：永远不要用纯LLM做数值判断，也不要企图用纯规则做综合解读。混合架构才是企业级AI的正解。
数值判断为什么不用LLM？因为LLM本质上是预测下一个词的概率模型，它的数学能力是“附带的”，不是“内建的”。让它判断6.8是否超过6.1，它答对两百次后偶尔会莫名答错一次。可这在医疗场景就是致命事故。规则引擎做这种判断，一秒钟跑十万条都不会错，为什么不上规则？
综合解读为什么不用纯规则？因为规则写不出“你的低密度脂蛋白偏高，且结合你平时应酬较多，建议控制动物性脂肪摄入”这种带有语境的自然语言。规则只能生成模板拼凑的干瘪句子，用户体验很差。
所以我的推理层设计是：
- 规则引擎负责确定性逻辑：指标是否超标、严重程度、风险评分、异常列表。这部分输出结构化数据，比如
{"risks": [...], "score": 4}。 - LLM负责生成类任务：基于规则引擎的输出，写一段通顺、有温度的解读和建议。它没有决策权，只有表达权。
- LLM生成后，规则引擎再做一道“护栏校验”。比如规则引擎只检出低风险，LLM却说什么“建议尽快就医”，这种不匹配的输出直接拦截。
画一条底线：模型可以帮你写作文，但数字判断和风险等级这类“结论”必须由确定性代码说了算。这是我踩过无数坑之后总结出来的铁律。
2.3 输出层：结构化、可校验、可审计
输出层是所有“看起来很美”的AI落地项目最后阵亡的地方。Skill的输出如果只是一段Markdown文本，AI能力就永远无法和现有业务系统对接。你必须让它输出固定结构，并且能够被机器校验。
我给Skill定了统一输出schema：
{ "summary": "本次体检整体未见明显异常，但空腹血糖处于偏高临界值，建议复查。", "risk_level": "moderate", "risks": [ {"code": "GLU", "name": "空腹血糖", "value": "6.8", "ref": "3.9-6.1", "level": "high"} ], "suggestions": [ "建议两周后复查空腹血糖", "平时注意减少含糖饮料摄入" ], "citations": [ {"source": "血糖(空腹) 化验单", "indicator_code": "GLU"} ], "confidence": 0.92 }每个结论都带citations（引用了哪份报告哪个指标），每条建议都注明依据；risk_level和confidence让业务系统方便决定怎么展示、是否升级人工处理。输出层还要做schema校验，不符合直接走兜底逻辑，宁可返回“数据不足，无法生成建议”，也不能输出幻觉内容。
三层解耦最大的红利是：换模型、加数据源、改提示词，都在各自层内完成，不会伤筋动骨。这才是“可复制”的Skill架构。
2.4 三层解耦带来的实际价值
可能有人觉得，解耦之后代码量变大了，没必要。我用一件真实的事说明。
之前我在一个项目里给客户做合同审核Skill，第一版把所有逻辑塞进一个Prompt，上线两周后客户说某个条款类型识别错乱。我们排查半天，最后发现是修改人把Prompt里关于“违约金条款”的描述改坏了，连带“责任限制条款”的识别也崩了。因为两条规则在同一个Prompt上下文窗口里缠在一起。
重构之后，我们将条款拆分为独立的输入解析、条款分类规则、输出校验三层。后续再改Prompt，改动被限制在推理层，输出层和输入层的测试全部通过，回归成本极低。
这件事让我彻底意识到一个道理：Skill封装的本质是降低系统的熵值。解耦不是为了代码好看，是为了让变化是局部的、可控的、可测试的。企业级AI环境里，需求每星期变一次，如果没有这种隔离能力，维护成本会把团队拖垮。
3. 手把手实操：把一个体检报告Skill做出来并跑通
这一章直接上实操，我尽量按“可以复制照跑”的颗粒度来写。真实项目里我会用Python，因为这个生态里处理PDF、做Web服务、写规则引擎都方便。
3.1 选型与准备：不是越重的框架越好
先说工具选型，我推荐的组合是：
- PDF解析：
pdfplumber。纯文本型PDF用它最稳；如果报告是扫描件，加PaddleOCR做文字识别。 - Web服务：
FastAPI。轻量、异步、自带接口文档，适合把Skill快速暴露成HTTP服务。 - 规则引擎：不引入额外工具，直接写Python函数。企业级场景如果你有大量复杂规则，可以考虑
Drools或规则集服务，但对大多数落地项目，Python函数足够。 - LLM调用：如果走API，
OpenAI SDK或者requests都行；若企业内部有私有化部署的模型，统一封装一个llm_client。
很多团队一来就上LangChain、LangGraph这类框架。我不反对框架，但我强烈建议：核心逻辑不要依赖框架。你自己的中间数据结构、规则函数、校验逻辑，都是纯Python模块，框架只是外壳。否则框架一升级，底层API一变，整个Skill跟着抖。
3.2 第一步：搭指标基准库
体检报告Skill的“地基”是一个指标基准库，它决定了你能否准确识别指标、匹配参考范围。我把基准库设计成一张标准表：
{ "code": "HGB", "name": "血红蛋白", "aliases": ["血红蛋白", "HGB", "Hb", "Hemoglobin"], "unit": "g/L", "ref_ranges": [ {"gender": "male", "age_min": 18, "age_max": 60, "low": 130, "high": 175}, {"gender": "male", "age_min": 61, "age_max": 120, "low": 120, "high": 175}, {"gender": "female", "age_min": 18, "age_max": 60, "low": 115, "high": 150} ] }这个库的维护成本不高，但你最好把它放到独立配置文件或数据库，不要写死在代码里。为什么？因为医学参考范围会变，不同实验室的参考标准也有差异，你要是写死在代码里，后面更新就是灾难。
3.3 第二步：写报告解析器
解析器是最“脏”的部分，我直接给一个能跑的骨架：
import pdfplumber import re def extract_report_text(pdf_path: str) -> str: with pdfplumber.open(pdf_path) as pdf: return "\n".join(page.extract_text() or "" for page in pdf.pages) INDICATOR_LINE = re.compile( r"(?P<name>[\u4e00-\u9fa5A-Za-z0-9+\.%()\/]+?)\s+" r"(?P<result>[-+]?\d+\.?\d*|阴性|阳性|未见异常)\s*" r"(?P<unit>[^\s]+)?\s*" r"(?P<flag>[↑↓H L*]?)\s*" ) raw_text = extract_report_text("report.pdf") for line in raw_text.splitlines(): m = INDICATOR_LINE.match(line.strip()) if m: name = m.group("name").strip() result = m.group("result").strip() print(name, result)写这个解析器的时候，有一个非常重要的“心力修为”：解析器不可能一次写对，你需要准备一个“样本库”，把不同机构的报告各放几份，每次改完正则都要全量回归。只拿一份报告调试，你会被正则表达式带进沟里。
另外要说明，上面的正则在真实项目里还会继续演进：指标名可能是纯英文缩写（如LDL-C），数值和单位之间可能没有空格，异常值前面可能有*。我的经验是：正则只做粗筛，后续字段映射和值标准化在规则函数里做，不要指望一个正则在文本层把所有事情干完。
3.4 第三步：实现规则引擎
规则引擎做三件事：识别异常指标、计算严重程度、生成风险评分。给一个高度简化的示例：
def find_ref(item, patient): for ref in REF_LIBRARY.get(item["code"], []): gender_ok = ref["gender"] == patient["gender"] age_ok = ref["age_min"] <= patient["age"] <= ref["age_max"] if gender_ok and age_ok: return ref return None def evaluate_indicators(indicators, patient): risks = [] score = 0 for item in indicators: ref = find_ref(item, patient) if ref is None: continue value = float(item["value"]) if value < ref["low"] or value > ref["high"]: deviation = max((ref["low"] - value) / ref["low"], (value - ref["high"]) / ref["high"]) severity = 1 if deviation < 0.1 else (2 if deviation < 0.3 else 3) risks.append({ "code": item["code"], "value": value, "unit": item.get("unit", ""), "ref": f"{ref['low']}-{ref['high']}", "severity": severity }) score += severity * 10 return {"risks": risks, "score": score}这套规则函数很朴素，却把“确定性”牢牢握在手里。每次规则引擎改动，都需要配套单元测试。我甚至会在团队里强制要求：规则引擎的测试覆盖率必须达到100%，这部分代码不允许模糊逻辑，每个分支都必须有明确输入和预期输出。
3.5 第四步：Prompt模板与输出校验
Prompt模板不是随口写一段话，它是推理层的工作文档。我给自己的模板定了固定结构：
[SYSTEM] 你是一名全科医生，负责解读结构化体检数据。 规则： 1. 只能使用给定的数据，不得推测或编造缺失指标。 2. 结论必须与给定的异常列表保持一致。 3. 输出JSON格式，包含summary、risk_level、suggestions。 [CONTEXT] 指标摘要：{summary_table} 异常列表：{risk_list} 风险评分：{score}（满分100，<30为低风险，30-60为中风险，>60为高风险） [FEW-SHOT] 输入：... 输出：... 请基于以上数据生成解读。这里的{summary_table}和{risk_list}就是前几层生成的中间结构，我把它们渲染成Markdown表格塞进Context。这样做的好处是：LLM不需要自己去整份报告里找数字，它看到的是人也能看懂的“体检摘要”，生成质量会稳定很多。
输出校验这一环，我用jsonschema做强校验：
import jsonschema OUTPUT_SCHEMA = { "type": "object", "required": ["summary", "risk_level", "suggestions"], "properties": { "summary": {"type": "string"}, "risk_level": {"enum": ["low", "moderate", "high", "unknown"]}, "suggestions": { "type": "array", "items": {"type": "string"} } } } jsonschema.validate(parsed_output, OUTPUT_SCHEMA)校验不通过的处理策略：第一个动作是“重试一次”，如果换了种子还是失败，就走兜底逻辑——根据规则引擎的输出套预设模板，直接告诉用户“当前数据生成解读失败，请咨询线下医生”。绝不让一张错误报告漏出去。
3.6 第五步：封装成API并加可观测性
最后一步，把整个Skill包成一个FastAPI接口：
from fastapi import FastAPI, Header, HTTPException app = FastAPI() @app.post("/v1/skill/health-report/analyze") def analyze_health_report( request: ReportRequest, x_api_key: str = Header(...) ): # 鉴权 if not validate_api_key(x_api_key): raise HTTPException(status_code=401, detail="invalid api key") # 解析 raw_text = extract_report_text_from_pdf(request.pdf_base64) indicators = parse_indicators(raw_text) # 标准化 + 规则 standard_indicators = standardize(indicators, request.patient) rule_result = evaluate_indicators(standard_indicators, request.patient) # LLM生成 + 输出校验 output = generate_interpretation(rule_result) output = validate_or_fallback(output, rule_result) # 写审计日志 audit_log(request, rule_result, output) return output除了基本接口，企业级部署少不了三件套：鉴权（API Key或OAuth）、限流（防止一个人把整月Token额度打爆）、请求ID（从入口到日志到LLM调用全程透传，方便排查链路问题）。
还有一个很多人忽略的点：记录输入输出的审计日志。这一点在医疗场景天然需要，在企业场景同样重要，因为一旦出问题，你要能回答“当时AI看到了什么、回答了什么、依据是什么”。没有审计日志，出了问题只能干瞪眼。
3.7 测试评估：怎么定量判断Skill质量
Skill不是写了就完事，你需要一套评估集来回答“这个Skill到底好不好用”。我自己的做法是建一个评测集，包含20到30份模拟体检报告，覆盖：
- 不同机构排版样式（公立、私立、App导出）
- 不同异常组合（单一指标偏高、多指标协同异常、单纯临界值）
- 边界情况（老年患者、孕妇、指标缺失、单位不标准）
每份报告找医学背景的人做标注，标准答案包含：异常指标清单、风险等级、建议方向。然后跑回归，看四个关键指标：
- 指标识别覆盖率：报告里有多少指标被Skill正确提取。
- 异常判断一致率：Skill判定的异常列表和标准答案的匹配度。
- 输出合规率：多少输出通过了JSON校验，没有幻觉。
- 平均响应时间：单份报告从进到出的耗时。
我的经验值是：前两个指标低于90%，这个Skill就别上生产；输出合规率要做到99%以上，靠兜底逻辑托底；响应时间视场景而定，但一般控制在15秒内比较好，超时就考虑用异步任务。
4. 落地中的坑与排查实录
这一章分享真实项目里遇到的坑，每一条都是我交了学费换来的，希望能帮你少走弯路。
4.1 高频问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决办法 |
|---|---|---|---|
| PDF抽出来的文本乱码、缺行 | 报告是扫描件或混排 | 检查是否有OCR文字层 | 用PaddleOCR补一层识别，并保留原有文字层结果做交叉 |
| 指标名匹配不上基准库 | 别名表不完整 | 打印出未命中的原始指标名 | 持续补充aliases，构造“未匹配指标”告警 |
| 数值被误判成异常 | 单位没有统一换算 | 检查原报告单位是否为mg/dL | 写死单位换算函数，并加入单测 |
| LLM输出格式经常不稳定 | 提示词约束不够或模型本身弱 | 查看原始输出与schema差异 | 加few-shot示例 + 输出后强校验，必要时重试 |
| 参考范围不适用 | 未区分年龄、性别 | 核对find_ref逻辑 | 给ref_ranges增加gender/age条件 |
| 并发一高就超时 | LLM串行调用 | 查看日志确认瓶颈 | 加并发池、批量prompt、超时重试 |
这张表是我在项目里的“排障手册”，每次开发新Skill我都会复制一份，把新的坑加进去。
4.2 三个让我记忆犹新的踩坑事件
先说第一个，正则误匹配。当时解析一份报告，发现“总胆固醇”的数值被错误地算到了“非高密度脂蛋白胆固醇”头上。原因很简单，我的指标名正则写成了[\u4e00-\u9fa5A-Za-z0-9]+这种贪婪匹配，而“非高密度脂蛋白胆固醇”以“高密度脂蛋白胆固醇”结尾，两个名称在未加锚点的情况下被正则吞并了。这件事之后我养成了一个习惯：解析器的每个正则都要配上“穿插式负向断言”，并且给每个指标名做最长匹配优先排序。这个坑你如果做任何文本解析迟早会踩到，早踩早修。
第二个是LLM输出幻觉。规则引擎明明只检出一项低风险异常，LLM生成解读时却擅自加了“建议尽快进行心电图检查”。这类幻觉如果你只在人工抽检里看，概率很低；但一旦上线全量，每天几千份报告里就可能溜出去几十个。后来我上了双保险：一是把风险评分和异常列表直接渲染进Prompt并附上“只能解释已有异常”的强约束；二是输出后再跑一次规则校验，检查LLM的risk_level与规则引擎评分是否一致。不一致就落兜底模板。
第三个最严重，单位换算错误。某份报告的空腹血糖是“5.6 mmol/L”，解析器却把它当成了“5.6 mg/dL”（美国单位）。两个单位相差18倍，后者会被判为严重异常。但初始化时我把单位默认值写成了mg/dL，而国内绝大多数报告单位是mmol/L，于是一整批报告的计算结果全部发生偏差。还好我们在全量上线前做了回归测试，否则这个事故就能写进年度故障复盘。现在我的代码里，任何涉及单位的字段都必须显式标注单位，不继承默认值，不依赖隐式约定。
4.3 企业级部署的这些细节别忽略
除了排障，企业级部署还有几个容易被忽略的细节。
第一个是数据隐私。体检报告属于个人健康信息，脱敏是底线。报告里的姓名、身份证号、联系方式，在解析和LLM调用前就要脱敏；LLM日志不能带原始敏感字段。很多内部系统其实评估过“用公有云大模型处理用户隐私数据的合规性”，结果都被否了，最后选了私有化部署。你如果在企业里做，千万别忽视这一层，否则法务会来找你。
第二个是成本控制。LLM调用贵，尤其是每次把整份报告塞进上下文，Token消耗很吓人。我一般会把“规则引擎直接判断为完全正常”的报告直接走模板输出，不调LLM，省下大约三成的成本；只有存在异常的报告才进入LLM生成流程。这个分支策略对线上成本影响巨大，你可以针对自己场景算一笔账。
第三个是滚动升级与回滚。Skill升级不是“改了代码就完事”。我要求所有Skill都必须版本化：上线新版本前一天先跑评估集比较新旧版本四项质量指标，再用小流量灰度，最后全量。一旦线上告警，立即切回旧版本。这个机制救过我很多次，比如一次Prompt升级导致某类报告输出合规率暴跌，灰度阶段就拦住了。
5. Skill心法进阶：设计一套体系而不是一个点
走到这一步，你已经会封装单个Skill了。真正拉开差距的，是你会不会把它演进成一套可以复用的Skill体系。
5.1 Skill复用与编排
单点Skill做得再好，如果不可编排，价值有限。我在实际项目里会把“体检报告解读Skill”拆成更细的原子能力：
- 数据解析Skill：负责PDF解析、字段映射、单位清洗，输出中间结构。这个Skill可以被任何“需要从非结构化文档提取结构化信息”的场景复用。
- 指标评估Skill：负责规则引擎、风险评分，输出机器可读的异常列表。它和体检报告没有强绑定，换成财务指标、设备参数同样能用。
- 报告生成Skill：负责LLM生成自然语言解读，并做输出校验。它依赖统一的schema，不关心上游业务。
这三个Skill之间用统一的输入输出Schema衔接。然后上层可以编排一个“体检综合报告Skill”，也可以把“指标评估Skill”单独拿出来给另一个“慢病随访AI”用。今天你花大力气设计的这三个原子能力，未来可能被三倍的项目复用。所以我会特别强调：不要在第一个项目里就把Skill业务逻辑写死成一个巨无霸，拆成原子能力，后面才香。
5.2 版本管理：Skill是会过期的
很多人以为Skill写好了就一劳永逸。实际上Skill的过期性比你预想得来得更快。
医学领域，机构更新了参考范围；企业领域，业务规则变了、产品字段变了、政策法规调整了。你的规则引擎和Prompt都会跟着失准。所以我建议每个Skill都要有“版本”概念，至少包含三个字段：version、effective_date、deprecated_date。
更新流程也固定化。每次变更，必须跑一遍评估集做回归，确认质量指标没有回退。如果指标下降，给产品决策者一份对比报告，让他们决定是保持现状还是承担风险上线。
哪怕是省一点Token的模板逻辑，也要进评估集，因为小改动可能引起连锁反应。我见过太多团队因为“就改一行正则”而引发线上事故，原因就是没跑回归。
5.3 一点经验之外的提醒
最后分享一个我个人的体会。
我做AI落地这几年有一个很深的感受：大模型的能力当然很重要，但企业级AI能不能真正跑起来，真正拼的是“工程封装”。一个把数据收拾干净、把输出卡得死死的Skill，即使模型一般，也能在业务里稳定带来价值；反过来，模型再强，如果你不做输入标准化、不做输出校验，它也只是个华丽的幻觉发生器。
所以每次拿到一个新项目，我都会先问三个问题：数据有多脏？结论错了能不能兜住？输出能不能被业务系统直接消费？这三个问题想清楚了，Skill的骨架也就基本确定了。体检报告只是我练手的第一个沙盒，但方法论是通用的。你在这个沙盒里把“从脏数据到可靠输出”的链路修炼扎实了，再去面对企业里庞大复杂的业务场景，心里就有底了。
