• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Usrename
V2EX  ›  程序员

各位阿莫迪, Viber coding 时候,关于团队协同,和较复杂的中大项目,有哪些最佳实现?

  •  
  •   Usrename · May 30 · 939 views
    多个人都在 viber 的时候,进行更好协同方面,有什么最佳实践吗?

    怎样降低猪队友的负面影响?(假设世事无完美)

    项目复杂度上升,有什么在早期设计和工程管理方面,以及逐步进入深水区,需要特别注意的地方?
    2 replies    2026-05-31 19:13:50 +08:00
    zzsong
        1
    zzsong  
       14h 6m ago
    这属于架构设计问题吧,设计初期就要做好子域划分,每个子域一个负责人。跨子域调用走 internal-api ,涉及到 internal-api 由技术 Leader 协调设计,然后各开发各的。
    Perchouli
        2
    Perchouli  
       6h 17m ago
    多人协作的目前最容易落地的应该是“中间产物”和“共享上下文”。前者就是在“意图”和“代码”之间,有一个记录,将自然语言意图编译为可读、可编辑且受版本控制的结构化中间表示,根据团队成熟度用 Spec 文件,用图(转 spec ),用自己实现的其他格式都有。“共享上下文”是项目里用 AGENTS.md 、.cursorrules 、architecture.md 控制好大的约束,然后用其他记忆管理比如 mem0 动态记录项目变化,比如一个配置文件用 TOML 写了被记录到记忆里,另一个人像用 YAML 写,在上下文里发现冲突就能拦掉。

    猪队友——文明一点叫低效协作者,影响主要集中在倾向于快速接受 AI 生成的第一个“能跑”的方案。降低方式主要是人工审核了,另一个实践是引入发散性思维的显式脚手架,就是让低效协作者在接受这个方案之间,先让 AI 多给一些其他方案做选择。

    如果一直都是 vibe coding ,“能跑”会累积成复杂的缺陷,传统的单测被认为会失效。有一种实践是强制要求 AI 生成一个映射表,将 Prompt 中的每一句话(业务意图)精确映射到具体的代码行(类/函数)和具体的验证点上。审查这个会比审查代码细节更能发现早期的规范缺失。我前两天还 share 了一个做法,也是一种可供参考的实践: https://v2ex.com/t/1216271

    至于“最佳”估计很难说,毕竟去年刚提出来的概念,模型也还在更新。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1152 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 17:31 · PVG 01:31 · LAX 10:31 · JFK 13:31
    ♥ Do have faith in what you're doing.