Cursor 开发的过程实录

效果总结：在(不连续的)5 天内，合计花费约 21 小时，达成 45 次 commit ，产出代码约 1500 行。测试用例（ tests/）：约 447 行源代码文件（ src/）：约 1,259 行
- 第 1 天, 250 分钟=70+180 ，询问 AI 并想通了反射，配合 AI 写反射，4 次 commmit
- 第 2 天, 120 分钟=60+40+20 ，类型，序列化，data-driven 端口类型，11 次 commit
- 第 3 天, 220 分钟=60+45+60+60 ，思考状态机，端口类型，数据驱动，数据类型和序列化，11 次 commit
- 第 4 天, 300 分钟=70+100+130 ，Trigger 思路，端口类型，端口类型 OK ，6 次 commit
- 第 5 天, 390 分钟=60+50+280 ，计时器，组件网络，UI 组件，13 次 commit
开发过程摘要：
- 是开发自己的项目( 参考这个 /t/862672 )。工具选的是 Cursor ，设置为 agent 模式，自动选择非 Thinking 模式的大模型。编码过程一般是我手动列出我想要做什么，想要修改什么，然后由它完成编码，我选择是否 Accept 。整个下来由自己来写的非常非常少。有时即使是删除某些代码，我也命令它来做。不过为了把事情说清楚，字倒是打了不少，这块不知道有没有语音转文字之类的可以加速呢。
- 泛型这块，我不是很熟，但我又非常希望利用 TypeScript 的类型系统来简化代码、增强类型检查。所以这块花了比较长时间的磨合。AI 在这方面就像一个 Master 大师，泛型写的很漂亮。我不熟悉，所以每次它写完我都要尝试去弄懂这些泛型是怎么工作的，能不能达到目的。下面有一个很简单的举例，如果让我自己去实现这些复杂的类型系统，那可真要把我愁死了。
- 到第 5 天，架子搭起来了，demo 跑通了，demo 用了 3 个组件，包括下面的 sequence 组件。效果如下图： https://v2ex.com/i/7M4536kk.gif
  - ```
  @RegisterComponent()
  export class SequenceBuffer<T> extends BaseComponent<SequenceBufferInputs<T>, SequenceBufferOutputs<T>> {
    private sequence: T[] = [];
    public metadata: ComponentMetadata<SequenceBufferInputs<T>, SequenceBufferOutputs<T>>;
    public inputs: ComponentInputs<SequenceBufferInputs<T>>;
  }
  export interface ComponentMetadata<Inputs, Outputs> {
    name: string;
    description?: string;
    inputs: PortMetadataMap<Inputs>;
    outputs: PortMetadataMap<Outputs>;
  }
  export type PortMetadataMap<T> = {
    [K in keyof T]: PortMetadata<T[K]>;
  };
```
- 虽然代码产出数量没达到 100 行/小时，但考虑到这里面包含了不少思考和调试的时间，且代码是紧凑的基础结构，并且还是自己不熟悉的领域，特别是有些工程配置浪费了一些时间，在各种 debuff 叠满的情况下，这效率算是非常不错了。最关键是编码过程很轻松，做的还是自己喜欢的作品，有种上瘾的感觉。
- 自己从顶层把握，做出一些关键的判断和选择，且不需要干什么费力的活儿，偶尔能对着吭哧吭哧干活的 AI 指点江山，获得一些临时的优越感(我也不知道自己为什么要跟机器比优越感)，这种感觉确实很不错。不过，谁知道这种日子还能持续多久呢，现在很多情况下，我只是在从 AI 提供的候选方案中选择一个合适的，其实方案也并不是我自己想出来的。当然，也有一些自己想到而 AI 没有想到的。

sentinelK

105 天前

“虽然代码产出数量没达到 100 行/小时”
其实 AI 赋能不能看绝对值。更恰当的比较应该是，同样的人，实现同样的功能。用 AI 和不用 AI ，产出的效率。

按照我目前的经验，合理使用 AI ，纯从代码量上考量，应该能放大个人生产力 5~10 倍。

btw：当然，因为生产力提升，代码实现的逻辑也会与没有 AI 时有本质的区别（比如技术选型更激进、更容易偏好于代码量大，但更稳健的业务逻辑等）。

这也会影响代码量之比。所以“代码量之比”也并不是合理的生产力提升衡量标准。
但这其实是另外一个话题了，就不赘述了。