zsyevan

1. 所有仓库全部放在一个目录下，在此目录下工作。
2. AGENT.md 里标注关联仓库的具体位置及作用。

描述产品是什么、验收标准描述、验证产品（验证代码、跑、修复 bug ），是超级消耗 token 。人力也要考虑进去，所以成本并不低

@coderwitt @conky 这个需求这么小众，两位大佬是怎么做到如此快的留言关联性极高的帖子的？

navicat 很多时候是为了审计采用，要么很多免费的 sql client 也够。

发现问题，定义问题，解决问题。

软件架构先从可观测性入手。可观测性又分为：软件运行时可观测性，开发可观测性，用户可观测性。

软件运行时可观测性目前业界主流就是 OpenTelemetry 那一套，再补充程序崩溃上报。
开发可观测性考虑的是协作流程，以及问题/feature 闭环，以前主要是瀑布流、TDD 等来解决，现在 人类和 AI 协作上还没有很好的可观测方案。
用户可观测性就是用户分析那一套， 开源项目有 umami ，postHug ，免费资源 google analaysis 。


定义问题：大部分程序性的问题，在 AI 的加持下，都不是问题，剩下的非程序性问题， 就要思考维度介入，这个千人千面。

解决问题和定义问题一样，程序性问题没门槛，非程序性问题，例如：程序到底多快才可以，要承载多少用户才可以，动画流畅性到底多少 fps 才达标...，这些 ai 只能告诉你业界的最佳实践是什么，但如何取舍还是靠自己。没有营养的说法是：将手头上的资本资源、人力资源、已积累资源做个整合，解决主要矛盾，减少对次要矛盾关注。

如何提升，虽然不想，但还是忍不住将其归结为“天赋”。

应该类似先前的云厂商，干脏活、累活。至于插件形式，按照大厂的尿性，一定是想做自己的生态，让你离不开他们。

个人开发者开发插件，很难搞定收费问题。

1. prd ，用户故事 进入 git 管理
2. skill + subagent 要明确说明查阅 ... prd 、用户故事 文档
3. 定期整理 prd 、 用户故事文档, 确保和代码实现具有一致性

From 我自己维护的 AI 自动化 Web 开发 skills https://github.com/timzaak/web-dev-skills)

@Haku rust 编译产生的中间产物占用空间很大，最终产品还是小的

我的 rust 项目 target 目录经常 100GB 。代码行数不到 50w ，编译也很慢。 若是产品功能导向，还是慎重为好