Appearance
AI工作指引思考
约束级别
1. 自然语言级
这是当前最受关注、热度最高的约束层级。
所谓“人人都是产品经理”，只要能用自然语言表达需求，似乎就能驱动 AI 产出结果。然而，事情远没有这么简单。
目前流行的如“龙虾”、Skill 等机制，本质上都属于自然语言级别的约束。这类约束最大的特点是高度不可控，存在明显的二义性。
即便是完成一件简单任务，也可能需要冗长描述；而 AI 自行创建的 Skill，往往充斥着大量重复或模糊的表述。即便如此，关键细节仍可能未被清晰传达，导致上下文逐渐失控——描述得越多，AI 反而可能覆盖的细节越少，遗忘概率也越高。
当然，这一层级的优势也很明显：门槛极低，只要会说话，基本都能让 AI 生成一些初步成果。
2. 统一建模级
这一层级主要涉及 UML、SysML 以及 SysML v2 等建模语言。
与自然语言描述需求不同，这类语言聚焦于系统设计本身，其作用类似于工程中的设计图纸。
在此层面，对 AI 的约束已显著增强。只要遵循清晰的设计模型去“施工”，最终结果通常不会偏离太远。但要构建高质量模型，要求从业者不仅掌握建模方法，还需具备深厚行业经验和系统分析能力。
例如，12306 的票务核心模型、高并发场景下的秒杀业务模型，若在设计阶段存在缺陷，仅靠技术手段（如堆加服务器）很难突破性能瓶颈。此时，问题根源不在实现，而在模型本身。
3. 编程语言级
如果说建模是“画图纸”，那么这一层级就是“选材料”。
在软件工程中，这体现为最细粒度的实现约束。
比如：
- 操作 Redis 时如何保证原子性
- Kubernetes 中新增一个 Pod 需要哪些配置
- 某个服务必须使用哪种编程语言
这些细节往往是系统稳定性和功能正确性的关键所在。此类约束属于深度定制，虽然粒度极细，却是构建可靠、可复用系统不可或缺的一环。
个人积累
涉及三个维度的能力
1. 业务架构
这本质上是一种战略层面的分析能力。
产品该做什么、怎么做、能带来什么价值——这些决定了整个事情的方向。方向一旦偏差，后续努力可能事倍功半。
对个人而言，自己就是自己的“产品”：需要明确自身能提供什么核心价值，哪些事情真正值得投入。
2. 分析建模
包含两个方面：
- 建模能力：面对复杂问题时，能否从分析角度进行结构化拆解，并清晰表达其内在逻辑
- 经验积累：长期深耕某一领域至关重要。即便具备通用建模方法论，在成熟领域中，往往仍难以超越拥有十年一线经验的从业者
3. 设计实现
指技术上的广度与局部深度。
在 AI 时代，这一能力的重要性看似有所弱化，但仍不可或缺。要有效引导和约束 AI，前提是你至少在关键环节上比 AI 更懂问题本身。
AI建模
目前 AI 在软件工程中的应用主要分为两种模式：
1. 需求建模
这种模式通常被称为“氛围编程”，核心在于描述需求。需求可以非常简单，也可以像规范文档那样详细，但最终都是通过结果来约束软件行为。
优点
- 效率高：适合 Demo、POC 等项目，能快速见效，便于调研和初步验证。
缺点
- 后期维护困难：本质上是概率模型，需求变化时内部逻辑可能剧烈变化，导致结果难以控制。
- 结果不确定性：由于缺乏详细内部设计约束，系统行为不够稳定，尤其在复杂场景下。
2. 分析建模
这是我正在执行并深入研究的方向。
其核心思想是通过详细的内部设计图纸来约束 AI 的工作，类似于机械制造中规定线圈缠绕的具体圈数一样精确。
优点
- 确定性和稳定性：通过明确的设计模型约束 AI，确保系统稳定性和可预测性。
- 风险可控：适用于需要严格控制过程的产品，通过 AI 辅助构建一个确定性模型，约束创作边界。
缺点
- 效率较低：特别是在处理老旧项目时，前期需要花费大量时间通过 AI 逆向建模现有复杂设计，再进行重构或扩展。
对未来产品的预判
我认为未来的 AI 产品将分为两类：
1. 结果导向的概率型产品
这类产品注重最终价值，对过程要求相对宽松。即使 AI 做得不够精细，只要设定好需求和严格的验收规则，AI 仍然能够完成任务并修补问题。
2. 严谨的过程控制型产品
这类产品不仅关注最终结果，还要求过程和中途表现必须严格固定。AI 在这种产品中的角色主要是根据明确分析模型进行修改和实施，在风险可控框架下加速开发效率。
通过上述分析可以看出，不同类型的 AI 产品适用于不同的场景。对于追求效率和灵活性的需求导向产品，AI 可以充分发挥优势；而对于需要高度确定性和稳定性的分析导向产品，AI 则更多作为辅助工具，帮助提升开发效率和质量。