fde-discovery
Skill0 starsChanged 2 months agoMITView on GitHub
企业 AI 落地前期的问题发现与定义——把"系统不好用/效率低"等模糊抱怨翻译成可验证、可计算价值的问题定义。当用户描述的是模糊业务痛点而非明确技术需求时使用。
In this repository10 other files it gives its agents.
- llms.txtllms.txt
- content-pipelineSkill
- cost-quoteSkill
- doc-reviewSkill
- kb-buildSkill
- recon-chainSkill
- record-linkSkill
- semantic-layerSkill
- state-reminderSkill
- timeline-checkSkill
The file
Files
FDE Discovery · 问题发现与定义
对应案例：NO.2（车管所）、NO.8（ERP 物料）、NO.13（消防维保）、NO.20（经营透明） 的共同第一步："用户说不清需求"是常态，问题定义本身是 FDE 的第一交付物。
何时使用
- 客户只给出模糊诉求（"我们想用 AI""系统不好用""帮我提效"）
- 需求列表存在，但没有与业务结果连接的根因链
- 立项前需要判断"这个问题值不值得用 AI 解决"
流程
- 数据可得性检查（第一步永远是这个）：列出问题涉及的系统与数据， 逐项确认"能不能拿出来、能不能写回去"（案例 08/22 的教训：API 存在≠能用）。
- 流程影子观察：不依赖会议室访谈，按"谁在做→输入→输出→在哪卡住"记录 真实工作流；对一线人员用观察代替追问（案例 13：访谈环境拿不到真话）。
- 根因下钻：对表面抱怨连续追问"为什么→然后呢→最终影响了什么"， 直到触及可计算的业务结果（案例 08：搜索难→重复录入→错误采购→报废损失）。
- 用例打分：按 数据可得性 / 系统集成难度 / AI 可行性 / 业务复杂度 / 用户接受度 / 潜在价值 六维打分排序，剔除"能用简单自动化解决"的项。
- ROI 先行：项目开始前定义价值口径——"解决后一年省多少，数字怎么算， 谁来确认"（案例 08：客户认可的价值才算成立）。
- 产出问题定义卡：问题一句话 / 根因链 / 数据清单 / 验收指标草案 / 明确不做什么。
验收
- 问题定义卡完成且根因链每一环都有证据（访谈记录/系统截图/数据）
- 至少 1 个用例通过六维打分（总分 ≥ 18/30）
- ROI 口径获得业务方口头确认
边界
- 不在这一步讨论模型选型——先有问题，再谈技术
- 涉及业务规则变更的最终决策必须留 给甲方（案例 02："识别出来怎么办"交甲方）
- 组织与 KPI 调整不在本技能范围内（案例 14/17：一把手工程）
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.