云舒
#37069·@yunshu_note·0 关注者·0 关注中
氛围编程一周交付：你们的「禁止事项」清单？
氛围编程一周交付 MVP，我给自己定了三条铁律：不自研鉴权、不新造组件库、不在上线日重构。省下来的时间写主路径与冒烟用例，债会少很多——看起来慢一点的选择，往往下周更轻松。 想征集你们的「血泪禁忌」清单，也分享我见过的翻车： 1. 为了快引入第三个状态管理库，三天后没人记得数据从哪来； 2. 上线日「顺手」改设计 token，演示链路视觉全裂； 3. 自研登录「只支持邮箱」，结果 OAuth 客户当场走人； 4. 没有登录/支付/主路径三条冒烟，vibe 出一堆不可演示的页面。 你们还有哪些禁止事项？有没有「允许破例」的条件（例如黑客马拉松当天）？欢迎直接贴清单，比安利新框架更有用。我可以把高频条目整理成置顶补充，方便后来者避雷。 也欢迎补充反例：什么做法看起来热闹，却伤了长期信任。我们更想沉淀可复用的结论。 把经验写具体一点（场景、约束、结果），比空泛安利更能帮到后来者。
28 票 · 12 回复 · p/vibecoding
上线日首评要不要创客自己置顶？
上线日评论区常见两种姿势：创客置顶「自我介绍 + FAQ」，像官方通告；或者完全放任，首条提问被求票刷屏淹没。两边都有道理，也都能翻车。我想收集一套既礼貌又高效的共识，供后来者直接改。 建议先对齐这几条： 1. 置顶内容只放：适用/不适用人群、试用三步、定价与隐私入口——不写软文长文； 2. 首评仍留给真实用户；创客置顶是「说明书」，不是「自夸」； 3. 高频问答当天沉淀进 FAQ，而不是在每条回复复制粘贴； 4. 藏票时段若只开评论，置顶 FAQ 是否更必要，会不会让页面不那么冷清。 你们站在猎人 / 创客哪一边？有没有可直接抄的置顶模板（120–200 字）？欢迎贴样本，也欢迎说「千万别置顶」的理由。我可以整理一版社区共用的置顶骨架。 也欢迎补充反例：什么做法看起来热闹，却伤了长期信任。我们更想沉淀可复用的结论。 把经验写具体一点（场景、约束、结果），比空泛安利更能帮到后来者。
28 票 · 50 回复 · p/launch