即刻App年轻人的同好社区
下载
置顶创造概念就是在创造抽象层级，好的抽象可以降低协作成本，所以造词儿这个事儿也就不是个坏事，这是提升生产力必须要有的流程，不然程序员们估计还在写汇编语言。
坏的地方在于，市场太热的时候从业者们会急着造词争夺话语权，大家创造出来的大部分概念完全不具备一层好的抽象应该符合的基本要素，像 skill，agent，harness 这些东西到底是个啥也说不清楚，用户和较真的从业者们一遇上了也一头雾水，本来是一个应该造福大家的事情，最后实际产生的作用也就只有FOMO到了老板们然后老板们折腾下面的人。话又说回这条 post 的第一句的道理了，好的抽象可以降低协作成本，但是硬造出来的传播符号只能提高会议密度。
坏的地方在于，市场太热的时候从业者们会急着造词争夺话语权，大家创造出来的大部分概念完全不具备一层好的抽象应该符合的基本要素，像 skill，agent，harness 这些东西到底是个啥也说不清楚，用户和较真的从业者们一遇上了也一头雾水，本来是一个应该造福大家的事情，最后实际产生的作用也就只有FOMO到了老板们然后老板们折腾下面的人。话又说回这条 post 的第一句的道理了，好的抽象可以降低协作成本，但是硬造出来的传播符号只能提高会议密度。
8 00
我觉得其实不需要太多信息输入，也不需要太广的信息面，优先自己上手实验一下以及看看 anthropic 和 openai 和 gemini 的进展就行了。
好奇的奇异果: 相信Beta，身边自然就会聚集一批创造Beta的人 相信Fomo，身边自然就会聚集一批制作Fomo的因子
9 10
在 Manus 的时候跟同事一起推动过一次研发部的「AI 工具使用」大跃进，这个大跃进的主要工作之一是要设计好给 ai 看的规则，好让 ai 完全接管写代码的流程，大概在 2025 年 6 月份整个 manus 内部已经达成了所有新代码全部都由 ai 生成。
当时能用的 ai 工具还不多，我们主要用的是 cursor，claude code，code rabbit，规则就是给他们几个做的，我们工程团队每个方向排了一个人维护所有的给这些 ai 工具看的规则，我当时负责 iOS 端的这块工作，每天会有 30% 的工作时间用来 review code rabbit 根据 mr 和 mr comment 自动产生的一条一条式的记忆，维护每位同事加的 cursor rules，根据之前设计好的代码架构和大家的开发习惯/约定补 rules，在项目里的各种位置思考要不要加一个 rules，这个维护工作现在新潮一点的叫法就是 harness 设计。
回到从工程师的工作内容角度看这个事情，首先 Coding Agent 没带来代码运行逻辑上的变化，以前运行在机器上的 if else 现在还是 if else，他改变的是工程师的工作重心，工程师之前的工作宏观来说是两部分，第一部分是分析产品需求、沟通、设计抽象和架构，第二部分是写代码落地，验证以及 review。这两部分之间是由“设计抽象和架构”串联起来的，harness 设计工作的目的就是为了方便 agent 完全接管后面的部分（然后随着大家用的越来越熟练可以逐渐进化成让前面的除了沟通外的部分也由 ai 辅助来做），所以设计 harness 其实也就是在做这个“设计抽象和架构”工作。
这块工作是工程师工作中最难做的一部分，架构讨论在研发工作里非常难达成一致，往往大家都要吵架吵很久，最后效率高一点的方式很多时候是老板拍个板；这个工作有一些前人总结出来的经验，可以根据实际的项目节奏选择，但实际基本没法原样完全套用，基本上都要为了项目节奏再进行调整。有本老书管这个类似的情况叫“没有银弹”。
现在各种关于 skills，soul.md，agents.md，自进化，design.md 等等 harness 的讨论是一场扩圈到程序员圈子外的项目通用性架构设计讨论，结合前面的工作经验分析，这些讨论可能最终也不会有个能解决所有问题的结论，大家根据自己的使用需求以及服务场景自己定制，大家各自去考虑自己要做的 trade-off。Agent 是一台精密的仪器，人需要习惯他就是个会来带思考负担的东西。
当时能用的 ai 工具还不多，我们主要用的是 cursor，claude code，code rabbit，规则就是给他们几个做的，我们工程团队每个方向排了一个人维护所有的给这些 ai 工具看的规则，我当时负责 iOS 端的这块工作，每天会有 30% 的工作时间用来 review code rabbit 根据 mr 和 mr comment 自动产生的一条一条式的记忆，维护每位同事加的 cursor rules，根据之前设计好的代码架构和大家的开发习惯/约定补 rules，在项目里的各种位置思考要不要加一个 rules，这个维护工作现在新潮一点的叫法就是 harness 设计。
回到从工程师的工作内容角度看这个事情，首先 Coding Agent 没带来代码运行逻辑上的变化，以前运行在机器上的 if else 现在还是 if else，他改变的是工程师的工作重心，工程师之前的工作宏观来说是两部分，第一部分是分析产品需求、沟通、设计抽象和架构，第二部分是写代码落地，验证以及 review。这两部分之间是由“设计抽象和架构”串联起来的，harness 设计工作的目的就是为了方便 agent 完全接管后面的部分（然后随着大家用的越来越熟练可以逐渐进化成让前面的除了沟通外的部分也由 ai 辅助来做），所以设计 harness 其实也就是在做这个“设计抽象和架构”工作。
这块工作是工程师工作中最难做的一部分，架构讨论在研发工作里非常难达成一致，往往大家都要吵架吵很久，最后效率高一点的方式很多时候是老板拍个板；这个工作有一些前人总结出来的经验，可以根据实际的项目节奏选择，但实际基本没法原样完全套用，基本上都要为了项目节奏再进行调整。有本老书管这个类似的情况叫“没有银弹”。
现在各种关于 skills，soul.md，agents.md，自进化，design.md 等等 harness 的讨论是一场扩圈到程序员圈子外的项目通用性架构设计讨论，结合前面的工作经验分析，这些讨论可能最终也不会有个能解决所有问题的结论，大家根据自己的使用需求以及服务场景自己定制，大家各自去考虑自己要做的 trade-off。Agent 是一台精密的仪器，人需要习惯他就是个会来带思考负担的东西。
63 724
如果我做投资，有一类项目我会要求看一个数据，就是那些还在邀请制内测阶段，提示可以去官网申请邀请码，然后在官网挂一个waitlist的项目，这些项目给多少waitlist里面的用户发了邀请码😁
我填过不少 waitlist，体感上能收到邀请码的比例不超过十分之一。
我填过不少 waitlist，体感上能收到邀请码的比例不超过十分之一。
4 30
