即刻App年轻人的同好社区
下载
DDD领域驱动设计方法论中，企业的业务通常被分为以下几个域：
1. 核心域（Core Domain） - 企业的核心竞争力所在，是最有价值的部分
2. 支撑域（Supporting Subdomain） - 支持核心域运作，但不是核心竞争力
3. 通用域（Generic Subdomain） - 通用的、可以在市场上购买或外包的部分
向企业提供服务，围绕这三块，完全是不同的打法。像 Palantir 做的是核心域，行业PaaS 应该做的是支撑域，而场景 SaaS 应该做通用域。如果错位就会很难受。
1. 核心域（Core Domain） - 企业的核心竞争力所在，是最有价值的部分
2. 支撑域（Supporting Subdomain） - 支持核心域运作，但不是核心竞争力
3. 通用域（Generic Subdomain） - 通用的、可以在市场上购买或外包的部分
向企业提供服务，围绕这三块，完全是不同的打法。像 Palantir 做的是核心域，行业PaaS 应该做的是支撑域，而场景 SaaS 应该做通用域。如果错位就会很难受。
1 00
实践了几个月企业内部平台的 skill 建设，感觉最主要的也就几个事。
研发 api 转 cli 基本很少二次封装，一是成本高，二是可能细项丢失能力。所以还是直接转最方便，但实际使用，还是需要对入参做简化，出参做过滤。要不然十几个入参，出参复杂的 json 结构，对模型挑战太大。在封装skill 的时候，沉淀好脚本，支持常见场景的入参转换，和出参数据清洗格式转换。这是教会模型使用 cli/api 的第一步。
第二步，真实的业务场景，过程中多是自然语言，从自然语言到参数的转化通常需要很多额外信息，一些常见参数的信息表，可以做一层 cache 。
第三步，skill 在不同平台输出，模型和 harness 工程的差异，效果无法保障，需要准备充分的测试集，以保障在目标环境的可用性。目前 skill 跟模型的耦合还比较高，未来有可能 skill 远程托管成 agent 保障稳定性是一个比较常选的路径。
随着模型能力的发展，反过来看最有价值的是业务评测集、稳定的 CLI/API 接口、关键的入参出参处理逻辑。其余都是当下的润滑剂，可能随着模型迭代慢慢变得无用。
研发 api 转 cli 基本很少二次封装，一是成本高，二是可能细项丢失能力。所以还是直接转最方便，但实际使用，还是需要对入参做简化，出参做过滤。要不然十几个入参，出参复杂的 json 结构，对模型挑战太大。在封装skill 的时候，沉淀好脚本，支持常见场景的入参转换，和出参数据清洗格式转换。这是教会模型使用 cli/api 的第一步。
第二步，真实的业务场景，过程中多是自然语言，从自然语言到参数的转化通常需要很多额外信息，一些常见参数的信息表，可以做一层 cache 。
第三步，skill 在不同平台输出，模型和 harness 工程的差异，效果无法保障，需要准备充分的测试集，以保障在目标环境的可用性。目前 skill 跟模型的耦合还比较高，未来有可能 skill 远程托管成 agent 保障稳定性是一个比较常选的路径。
随着模型能力的发展，反过来看最有价值的是业务评测集、稳定的 CLI/API 接口、关键的入参出参处理逻辑。其余都是当下的润滑剂，可能随着模型迭代慢慢变得无用。
3 01
最近看 palantir，感觉收费模式和 FDE 职责范围都不是最关键的，还是要看整体服务的溢价能力。FDE 如果人效低，就约等于人力外包，长期痛苦不堪。搞 FDE 还是要看下业务利润能不能支持高品质的服务，这又跟整体的市场环境、公司其他的核心竞争力有关。
桑文锋SensorsData: 上午组织了一场 20 人的 FDE 研讨会，持续了两个小时。整体聊下来，产品形态不同，FDE 的职责范围有所不同。对于我所关注的收费模式问题，在讨论中并不是最关键的，有的公司核心是靠产品收费，有的公司 FDE 就是收费的核心。 总的来说 FDE 要为客户结果负责，要交付场景价值，这是 forward。同时，又要在解决客户场景需求时，反向推动产品改进，甚至直接升级产品，这是 backward。传统的人力外包，可能并不关心业务结果，也没有反哺产品的机制。 在 AI Agent 时代，Agent 产品的成熟度，与客户的场景价值落地，往往有比较大的跨度，这个角色变得更加重要。 其实我更会联想到 Customer Success 和 Growth Hacker 两个角色。CS 为客户成功使用产品负责，但一般不需要直接交付场景。Growth Hacker 是奔着增长目标的全栈，比 FDE 更加结果导向，当然，本身也属于企业内部角色。
1 00
