理解真实业务
8 年企业软件经历，其中 7 年 HR 数字化。从需求调研、蓝图到配置、报表和试运行，熟悉方案进入组织的过程。
证据：绩效域独立实施孟进MeJnAI 产品经理 / FDE
长沙 · 一个月内到岗
长沙 · 一个月内到岗
把 AI 落进
真实工作。把业务问题，
接到可用系统。
8 年企业软件交付，7 年 HR 数字化。
我定义问题、做产品取舍，用 AI 协作构建，并在真实使用中验证。Java 开发起步，经历需求、方案与企业交付。
用 AI 协作构建，也负责问题、边界和验收。
业务现场的经验，产品判断的能力，AI 构建的实践。
向下认识我从业务一线，
走向 AI 产品。
我经历过 Java 开发、企业项目管理、售前与产品设计。现在，我把这些经验用于自主 AI 产品：先理解真实工作，再决定该做什么、怎样验证。
我的优势来自两条经历的交汇：长期企业交付与持续构建自己的产品。
开发技术与数据基础→交付组织与现场约束→产品需求与范围取舍→AI 实践构建与持续验证
把需求变成取舍
区分必须做、可用已有能力替代和暂留线下的环节。定义需求时，也定义范围、限制与验收标准。
证据：三个产品取舍用自己的产品验证
自主构建桌面 Agent、知识问答与排班原型。AI 协作实现，我负责问题与判断，并从日常使用继续修正。
证据：FatFish 日常协作代表作品与交付
先看 FatFish 桌面 AI Agent，再看企业绩效域实施。
一个是自主产品，一个是真实交付，分别说明用途与本人贡献。
FatFish 桌面 AI Agent
Windows 个人 AI Agent：语音对话、长期记忆、工具执行与工作回顾。
我的角色 · 产品定义 / 人格与能力边界 / 需求取舍 / 日常使用与验收；AI 协作实现
本人自用 · 小范围朋友试用 · 持续迭代
产品进展已形成对话、长期记忆、工具执行与工作回顾的桌面入口。
一天的协作，应该接得上下一次。
我想解决的，是任务、对话和记录分散之后，AI 每次都要重新理解上下文的问题。Daily Review 把当天真实记录组织起来，帮助我回看和继续。
- 真实问题
- 一天里聊了什么、实际完成了什么、还要继续什么，分散在不同记录里；一段聊天摘要难以交代清楚。
- 我的取舍
- 回顾先读本地结构化记录，用确定性聚合形成正文。会话提及不算任务；空白日如实显示没有记录，数字不交给模型自由生成。
- 已做出来
- 活动页“回顾”和只读回顾工具使用同一条聚合链；完成、进行中、未完成与建议继续，可以回到各自记录。
- 验证范围
- 本人日常使用与少量试用，尚未证明规模化采用或商业效果。实现和历史验证有记录，长期使用价值仍需更多真实反馈。
进一步：记忆、执行与我的责任
日常入口桌面角色、对话、语音与工作台放在一起。人格与主动行为需要日常校准，不能只把功能接进来。
记忆有来源记忆区分事实、偏好与决策，保留候选、人审和版本机制；旧记忆发生冲突时需要重新处理。
执行有边界读取、写入和高风险动作分别授权，重要动作提供确认入口；AI 不能自行放宽权限类设置。
失败可回看任务状态、运行记录和可撤销账本帮助排查与恢复。可撤销范围有明确限制，不承诺任意动作都能回滚。
我定义问题与验收选择日常场景、人格与权限边界，决定哪些行为值得接入；以真实使用发现问题，再拆成可验证的修改。
AI 协作实现代码与实现由 AI 协作完成。我负责需求、取舍与结果验收，不把使用 AI 等同于独立手写所有代码。
证据保留范围项目维护任务书、代码提交、回归套件与真机记录。2026-10-06 新装机检查选段记录为 35 通过、0 失败、6 跳过；仅代表该次范围。
本页核对已提交 v0.124.0 的能力；后续开发未纳入已完成主张。自用与试用不代表商业验证。
绩效域交付与 AI 工作流
在复杂交付里，保留人的判断，减少重复劳动。
我的角色 · 绩效模块独立实施负责人 / 人才标签方案兼责
真实业务交付 · 汉得驻场
验证 / 交付结果蓝图完成阶段签字回款，总部与 3 个战区试运行后启动全集团推广。
先做范围取舍，再把重复环节交给 AI。
绩效域交付里，调研、蓝图、方案评审和报表必须连成一条线。我在现场负责这条线，并把 AI 引入其中的重复环节。
- 事实
- 大型连锁企业绩效模块，从需求调研、蓝图、配置与报表，推进到试运行和推广。
- 我的判断
- 蓝图将绩效标签改用已有筛选方案；特批校准不落地，指标拆解跟踪保留线下。
- 仍有限制
- 真实业务结果属于 HR 系统交付；AI 工作流为个人方法，自主绩效 AI 工作台为验证产品。
进一步：产品机制与验证过程
真实交付依据是需求报告、绩效蓝图、阶段签字与试运行记录，客户原件未公开。这里保留本人职责与取舍说明；下方 AI 工作流与自主工作台分别表达，不作为客户生产系统截图。
三个工作流对应实施的三个重复环节——AI 出初稿和评审意见，人做业务判断和终审：
蓝图 AI 辅助设计调研材料 → AI 生成蓝图框架与方案文本 → 人工业务校准。30+ 业务场景的需求报告，从堆材料到成稿快一截。
客开方案 AI 评审客开需求 → AI 评估必要性、风险与替代方案 → 记录不做、已有能力替代与保留线下的范围取舍——需求不是照单全收，先过一遍筛。
报表 SQL AI 开发取数规则 → AI 生成语义模型 SQL → 测试环境验证后交付。20+ BI 报表与驾驶舱由此而来。
定位始终是辅助实施，不是替代判断——方案签字之前，每一处都过人眼。
2026 年 9 月，这条线做成了完整产线——以用友 BIP 绩效域为原型，自主搭建：
46 表本地绩效库从 BIP 测试环境抽取绩效主体表结构，双库同名建到本地；等级域、期间编码这类隐式口径从实测获得，不靠文档推测——后续 AI 项目的口径底座。
AI 绩效智能工作台（线上可演示）旁挂绩效数据的 AI 分析层：规则引擎算事实、LLM 做解读、证据链可下钻；工作台 / 智能关注 / 员工绩效画像 / 组织洞察 / NL2SQL 等七大模块。
HR AI 培训课件为客户 HR 部门准备的内训课件——网页互动而非 PPT，现场不用切屏，本身也是一件可交付物。
从「用 AI 辅助实施」走到「给绩效域做 AI 产品」——这条线还在往前长。
做一个 Agent，
也要决定它不该怎样做。
FatFish 的三个产品取舍。
把日常需要、实现机制与验证范围放在一起。
取舍 / 从真实记录开始
会话提及不算任务，空白日不编故事。
真实问题
生成式总结可能把聊过的事当成任务，或把没有记录的一天补成完整叙事。
我的判断
工作回顾先做本地只读聚合：任务来自结构化记录，会话只是背景，数字来自已存数据。
已实现机制
活动页与回顾工具使用同一条链；无记录明确返回空白，每项保留来源。
依据：013 产品任务书与已提交实现 · 能力核对至 2026-10-06
陪伴感与执行力，
需要一起设计。
人格化入口降低日常使用的距离；任务、记忆和权限机制让协作有明确范围。界面中的亲近感，不替代执行前的判断。
查看实现与验证依据
- Daily Review：本地结构化记录聚合，空白日与会话提及有独立口径。
- Memory：候选、人审与版本机制；冲突记忆需要重新处理。
- 执行：分级权限、确认与有限撤销，不承诺任意外部动作可回滚。
- 已提交 v0.124.0；新装机检查选段 35 通过、0 失败、6 跳过，未等同于全功能认证。
另外两种验证。
知识问答验证证据可靠性，智能排班验证评估纪律。
作为辅助作品，按需查看。
项目指引智能问答
把分散的制度资料，变成能查依据的回答。
我的角色 · 产品定义 / 架构与选型 / 评测与验收；AI 协作实现
自主原型 · 真实资料验证
验证 / 交付结果持续用于本人资料查询；保留 104 条对照评测问题，用回归判断修改是否有效。
答案必须能回到原文。
真实资料验证的自主原型；主要本人使用，尚未证明外部采用。
展开知识问答的判断与验证
答案必须能回到原文。
HR 场景需要可信的回答。我先定义证据与拒答行为，再把检索、规则、人才与数据查询接进同一套产品。
- 事实
- 自主部署知识问答产品，54 篇资料拆成 6,202 个知识单元，用真实项目资料验证。
- 我的判断
- 模型理解问题；规则、数据库和原文证据提供事实。没有直接依据时明确处理。
- 仍有限制
- 自主原型，非客户正式上线产品。历史问答量主要来自本人使用，未证明外部采用。
进一步：产品机制与验证过程
三种典型问题，对应三种设计行为。以下是前端流程示意与示例数据，不执行实时查询。
试试看：
Q试用期员工的绩效怎么算？
路由 → 制度类 · RAG检索 → 示例命中 3 个单元依据判定 → 支持
试用期员工纳入考核范围，按月度周期单独核算，指标由直接上级在试用期计划中下达……
依据：绩效操作手册 §4.2 · 试用期管理办法 §2.1
Q研发中心有几个 P6 以上的人？
路由 → 数据类 · SQL只读查询 · 白名单表审计留痕
示例结果：17 人。真实产品需完成只读校验、脱敏与审计。
单条 SELECT · 自动 LIMIT · 结果脱敏
Q公司年会大概什么时候办？
检索 → 0 命中依据判定 → 无关
未找到直接依据——知识库不含此类信息，不猜测、不硬答。
拒答优先于编造
无依据时明确说不知道，是这套系统被设计出来的原因之一——HR 场景里，一个编出来的答案比没有答案危险得多。
- 关键词 + 向量 + 实体感知三路召回
- 制度 / 规则 / 流程 / 人才 / 数据 五路分流
- 证据三分类：支持 / 不支持 / 无关
- 无依据 → 明确说不知道，不硬编
若业务方反馈「答案不准」，按这 8 步定位，而不是凭感觉调 prompt：
- 问题在知识范围内？
- 路由分对了吗？
- 正确单元进召回了吗？
- 排序把谁排前了？
- 证据门放过了弱证据？
- 模型超出证据发挥？
- 原始制度缺失/过期？
- 沉淀为评测用例，修复后回归。
SmartScheduler 药店智能排班
从经验排班，走向可解释的预测与规则。
我的角色 · 立项 / 数据方案 / 评估标准与验收；AI 协作实现
自主构建 · 模拟数据验证
展开本人判断与验证过程
好看的预测分数，需要能被复现。
客流影响排班，但药师配比、工时和休息是硬约束。我把需求拆成预测与约束求解两部分，并先约定怎样评价预测。
- 事实
- 设计客流预测与约束求解排班的完整流程，经历多轮方案与产品迭代。
- 我的判断
- 训练与预测窗口分开，固定评估协议，保留无效路线，避免用未来数据制造高分。
- 交付结果
- 记录 7 轮迭代与外部模型评审；形成可解释的预测、班表与约束验证流程。
- 仍有限制
- 模拟数据与离线验证阶段，未在门店生产运行。仍需真实门店数据、泛化与安全验证。
进一步：产品机制与验证过程
预测模型最容易自欺——把评估做严，比把模型调高更难也更重要。这套系统立了三条军规：
零泄露协议训练数据物理截断到 2026-06-30，7 月真实客流只用于打分，绝不进训练集——从根上杜绝「用未来预测过去」的假高分。
无效方案存档层级预测、log1p 损失、调容量……每条失败路线都记录在案，评审时不重复踩坑，也避免「忽然变好」的偶然被当成规律。
固定种子可复现同一版本跑 3 次，五项时段指标完全一致。说不清怎么复现的结果，不算结果。
历史模型评测形成了可复核记录；仍需真实门店数据与泛化验证，当前结果不作为生产承诺。
v5MVP 闭环
v6.0极简重构
v6.9NL2SQL 三层防线
v6.12约束 NLP 压测
v6.13自研 MeJn 模型
v6.14外部评审·灰度准入
历史评审留下了灰度准入条件。当前仍处模拟验证阶段，生产上线还需真实数据与安全验证。
开发起步，学会交付。
Java 开发 → 企业软件项目经理。经历零售 HR 系统全模块交付、数据集成与 CRM 项目上线。
走进需求，形成产品判断。
项目管理、售前与产品设计；从调研、蓝图、原型到客户培训，理解方案如何落进组织。
负责绩效域，推进真实交付。
需求、蓝图、配置、报表、试运行与推广，在企业现场承担完整模块责任。
自主构建，走向 AI 产品。
知识问答、智能排班和桌面 Agent；把业务经验带进问题定义、产品实现与证据验收。