01
需求澄清
把客户“想看一个整体倾向”转译为输入、处理、输出与验收。证据：企业年报文本分析。
What I Bring
从需求翻译到交付验证
四类能力分别对应真实交付、评测任务与受控工作流中的项目证据。
Engineering Footprint
Python
Java 21 / Spring Boot
SQL / SQLite
RAG / MCP
Tool Calling
02
方案拆解
明确模型、规则、界面与人工复核各自负责什么。证据：费用预检与 Text2SQL。
03
异常处理
将依赖缺失、工具失败和结果不可验证纳入方案。证据：客户环境适配与模型评测。
04
交付验证
以客户独立使用、结构化导出和验收结果确认完成范围。证据：真实付费交付。
Primary Case · Paid Delivery
企业年报文本分析：从模糊需求到付费验收
付费外部委托｜客户独立运行成功｜明确验收并付款｜客户资料保密
From vague goal to accepted delivery
NLP · Batch Processing · Windows GUI · Excel / CSV · Client Handover
Delivery Path
模糊业务目标从年报中筛选指定主题语句并标注情感，供投研人工整理与判断。
单企业 MVP先验证文本处理、关键词筛选、情感分类和结果输出链路。
批量输入与导出支持年报或 ZIP 批量输入，整理为 Excel / CSV 供人工复核。
Windows 环境适配处理运行环境与依赖问题，提供 Demo 和操作指南。
独立运行与验收客户按指南完成批量处理与结果导出，随后验收并付款。
从需求澄清到客户独立使用
客户需要从若干上市公司年报中筛选指定主题语句并识别情感态度，但没有指定技术实现。我负责把重复性文本处理收束为可批量输入、可结构化导出、可由非技术用户独立操作的桌面交付。
- 范围收敛将“人工筛读年报”收束为指定主题语句的筛选、句级情感标注与结构化输出，服务投研信息整理与人工研判。
- 交付形态根据客户的 Windows 使用环境交付桌面 GUI，支持拖拽上传年报或 ZIP 批量处理，并配套操作指南。
- 迭代范围先完成单企业版本，再按客户实际使用需要扩展多企业批处理和导出字段。
- 运行支持处理批量运行慢、报错和网络等使用问题，重新适配运行环境，并补充 Demo 与操作指南。
- 完成标准以客户按指南独立完成处理和导出、明确验收并付款作为项目完成的外部验证。
使用与展示范围
工具为投研信息整理与人工研判提供结构化输入，最终投资判断由使用者完成。客户资料按保密要求管理。
查看项目说明与可提供材料
Evaluation Decision · Evidence Pre-check
费用预检：把证据完整性与审批结论分开
课程模拟｜规则审核前的证据检查｜评测不达门槛，停止扩围
Evidence quality before policy review
证据预检 · 规则审核前置 · 人工补证
只让完整证据进入规则层
- 界定问题范围限定为证据完整性检查，费用会计继续负责最终审批。
- 定义分流票据、字段或特批证据缺失时返回
FLAG，并给出人工补证动作。 - 验证分流3/3 个证据预检样例与 12/12 条最小回归通过，固定缺证进入
FLAG的处理规则。 - 评测决策30 条样本的决策准确率为 63.33%，低于 80% 门槛，因此停止扩大自动化范围。
Course dataset · public-label evaluation
63.33%决策准确率
评测结果不支持扩围
我把范围限定为规则审核前的证据检查；证据缺失或冲突进入人工补证。30 条样本的决策准确率为 63.33%，低于自定 80% 门槛，因此停止扩围并保留人工复核。
- 流程验证
- 3/3 个证据预检样例、12/12 条最小回归通过（自测）
- 分流行为
- 证据缺失或冲突 →
FLAG→ 人工补证或核实 - 样本评测
- 30 条公开标注样本：决策准确率 63.33%、Precision 87.50%、Recall 82.35%（自测）
- 工作流范围
- 规则审核前的证据检查、状态分流与人工补证
下一步条件先补足业务样本、只读数据接入与影子运行证据，再重新判断是否扩大自动化。
查看评测方法与验证记录
Supporting Evidence
三组支撑证据：任务、行动与状态
三类项目分别保留自己的验证状态，用于补充任务评测、受控工作流与公开发布证据。
模型任务评测Failure Modes · Tool Use · Verifiability
模型评测：从回答质量扩展到任务完成
任务：在 OpenClaw 与 Hermes 两种执行环境下，对 5 个代号模型执行 3 类复合任务，检查工具调用、文件处理、代码执行、数据分析与产物保存。
- 行动：按上下文丢失、工具链路中断、产物格式不一致等失败模式归因。
- 状态：已形成复合任务记录与失败模式归因。
代号说明公开页沿用评测记录中的模型代号，重点呈现任务完成与失败类型，不作通用模型排名。
查看任务范围与评测记录
- 状态
- 外部众包评测
- 范围
- 5 个代号模型 · 3 类任务 · 2 种环境
- 产出
- 失败模式与 Badcase 判断
Text2SQLStateGraph · Approval · Retry · Audit
Text2SQL：把高风险查询变成受控状态机
任务：将自然语言查询拆成意图澄清、Schema 检索、SQL 生成、预校验、人工审批、执行、重试与审计。
- 行动：模糊意图先澄清；高风险 SQL 进入人工确认；失败后携带错误信息有限重试。
- 状态：在 SQLite 示例数据库完成源码、状态机与硬化测试验证。
- 状态
- 受控环境验证
- 核心
- 模型 + 校验 + 人工审批
- 证明
- 状态机工作流与风险兜底
科学营养顾问 SkillProfiles · Logs · Safety Boundaries
科学营养顾问：把建议组织成持续任务流
任务：将营养咨询拆为用户档案、目标计算、每日记录、进度看板、场景建议与周期复盘，覆盖 12+ 健康管理场景。
- 行动：设置特殊人群与医疗边界，完成中英文版本和公开发布。
- 状态：讯飞 Skill 比赛二等奖（官方公示）。
- 状态
- 公开发布
- 范围
- 12+ 场景 · 中英文版本
- 证明
- 状态设计与产品化闭环
Working Principles
我如何把方案推进到可交付
三条原则分别约束交付范围、失败处理和完成标准。
01
先做最窄可交付闭环
从输入、处理、输出与验收开始，用最小版本验证链路，再按真实需求扩展。
02
把失败路径和运行环境纳入方案
依赖缺失、工具失败、结果不可验证都需要明确的处理方式和责任边界。
03
以独立使用和验收确认完成
运行结果、操作指南与客户验收比“功能已做出”更接近真实交付标准。
Next Conversation
如果你的团队需要有人在模型能力与业务交付之间架桥
我希望参与 AI 方案的需求澄清、方案拆解、运行验证与交付闭环，让业务目标能够落到可运行、可验收的结果。