2 篇博文 含有标签「team」

评测集（eval set）是一个文件。但它也暗含了对 AI 功能用途的理论定义。这两者并非一回事，混淆它们的团队建立了一个质量网关，而其校准完全依赖于单个人的工作记忆。当那个人离职时，文件留下了，但那套理论也随之而去了。

这是你在组织架构图中看不到的失败模式。你规划了一个提示工程（prompt engineering）角色。你雇佣了一个优秀的人才。他们发布了 v1 版本的提示词，审视了简陋的基准测试，并将其重写为内容丰富的东西——一个失败模式分类法、每个类别的权重，以及一套能够消除边缘情况歧义的标注指南（rubric）。评测集变成了“该模型是否好到足以发布”的契约。六个季度后，你发现这份契约除了编写它的那个人之外，其他人都看不懂。

• 听客户的话

  • 持续不断地和客户沟通
    • 和客户做朋友是最简单的策略：一旦你们成为了朋友，你可以持续而且低门槛地找他们给反馈。到了一定程度，发短消息比email和开会来的容易。
  • 挑剔地挑选你服务的客户
    • 剔除对你解决的问题没有痛感的客户
    • 剔除客户想要，但是你还没做出来的 feature 的客户

• 快速执行

  • 界定刚刚好的范围
    • 通常，满足最最简单的 usecase，然后等着看人们还想要些什么。你自然就会知道接下来该做什么。
  • 培养解决问题的良好直觉
    • 产品是艺术与科学的结合。太过数据驱动的产品缺少灵魂和惊喜。如何练习直觉？尽可能不用代码去验证想法
  • 最大化自主权，推行 prioritization by persuasion 的文化。同时，允许团队基于他们的情绪、生活、兴趣来选择他们的工作。用说服力和动态调整来推进进度。