多个人都在 viber 的时候,进行更好协同方面,有什么最佳实践吗?
怎样降低猪队友的负面影响?(假设世事无完美)
项目复杂度上升,有什么在早期设计和工程管理方面,以及逐步进入深水区,需要特别注意的地方?
怎样降低猪队友的负面影响?(假设世事无完美)
项目复杂度上升,有什么在早期设计和工程管理方面,以及逐步进入深水区,需要特别注意的地方?
1
zzsong 17h 35m ago
这属于架构设计问题吧,设计初期就要做好子域划分,每个子域一个负责人。跨子域调用走 internal-api ,涉及到 internal-api 由技术 Leader 协调设计,然后各开发各的。
|
2
Perchouli 9h 46m ago
多人协作的目前最容易落地的应该是“中间产物”和“共享上下文”。前者就是在“意图”和“代码”之间,有一个记录,将自然语言意图编译为可读、可编辑且受版本控制的结构化中间表示,根据团队成熟度用 Spec 文件,用图(转 spec ),用自己实现的其他格式都有。“共享上下文”是项目里用 AGENTS.md 、.cursorrules 、architecture.md 控制好大的约束,然后用其他记忆管理比如 mem0 动态记录项目变化,比如一个配置文件用 TOML 写了被记录到记忆里,另一个人像用 YAML 写,在上下文里发现冲突就能拦掉。
猪队友——文明一点叫低效协作者,影响主要集中在倾向于快速接受 AI 生成的第一个“能跑”的方案。降低方式主要是人工审核了,另一个实践是引入发散性思维的显式脚手架,就是让低效协作者在接受这个方案之间,先让 AI 多给一些其他方案做选择。 如果一直都是 vibe coding ,“能跑”会累积成复杂的缺陷,传统的单测被认为会失效。有一种实践是强制要求 AI 生成一个映射表,将 Prompt 中的每一句话(业务意图)精确映射到具体的代码行(类/函数)和具体的验证点上。审查这个会比审查代码细节更能发现早期的规范缺失。我前两天还 share 了一个做法,也是一种可供参考的实践: https://v2ex.com/t/1216271 至于“最佳”估计很难说,毕竟去年刚提出来的概念,模型也还在更新。 |