每篇内容尽量从真实业务里的卡点开始，而不是先堆工具名和概念。
About Li Yue
关于李悦
这里是李悦的中文个人专业站，用来长期记录业务流程拆解、AI 业务系统搭建和产品化实践中的方法、判断和复盘。
它不是简历站，也不是服务销售页。我更希望这里保持克制、真实和可追溯：少一点包装，多一点对业务问题、流程结构和系统落地过程的整理。
真实经验流程视角长期复盘
把目标、节点、角色、数据和反馈摊开，再判断 AI 应该放在哪。
记录哪些做法值得沉淀，哪些只是阶段性尝试，不把探索包装成结论。
Focus
我主要关注的事情
这里更关注问题如何被拆清楚、流程如何被搭起来，以及一套做法是否能沉淀为可复用的系统结构。
业务问题拆解
先弄清楚真实问题、目标、角色、约束和卡点，避免把工具当成问题本身。
流程结构梳理
看输入、输出、节点、责任人和反馈机制，把业务发生的顺序摊开。
AI 业务系统搭建
判断 AI、工具和人分别应该承担什么角色，而不是为了使用 AI 而使用 AI。
产品化实践复盘
观察哪些流程、规则、模板和系统结构值得复用，哪些只是一次性尝试。
Working Method
我更习惯从流程进入，而不是从工具进入
AI 是否有用，通常不是从模型或工具开始判断，而是从业务里到底发生了什么开始判断。先看清问题，再看流程，再判断工具和人的分工，最后复盘能不能沉淀。
判断标准
如果一个节点本来目标不清、责任不清、反馈不清，接入 AI 只会让混乱更快发生。流程清楚之后，工具选择才有意义。
输出形态
这里的内容会更多沉淀成流程图、判断清单、复盘文章和可复用的系统结构，而不是把页面写成服务介绍。
-
01
看清问题
先确认目标、角色、现状和真正的卡点。
-
02
拆开流程
把输入、输出、节点、责任和判断点摊开。
-
03
判断分工
区分哪些适合 AI，哪些需要人判断，哪些只是工具连接。
-
04
复盘复用
看这套做法是否能沉淀为模板、规则、清单或系统结构。
Origin
这些判断来自哪里
过去我长期接触 IT 项目、项目管理和软件售前解决方案相关工作。相比某个岗位名称，真正留下来的，是理解业务问题、拆解流程、设计方案并推动落地的能力。
现在我把这些经验放到 AI 业务系统和产品化实践里，继续观察一件事：一个方案如何从想法变成流程，从流程变成系统，再从系统里沉淀出可以复用的部分。
Boundary
这里不会写成什么
关于页需要建立信任，但不需要把个人经历包装成销售话术。
不会用履历堆叠替代真实判断，也不会把页面写成职位和标签集合。
不会把探索、观察和阶段性尝试包装成确定成果，也不会虚构收益数字。
不会制造焦虑，不承诺收益，不用夸张话术推动转化。
Contact
如果你也在思考类似问题
如果你也在处理业务流程、AI 系统落地或产品化复盘中的具体问题，可以通过邮件做一次克制的交流。这里不承诺收益，也不做夸张包装，只围绕具体问题讨论。