[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-ai-feature-positioning-zh-CN":3,"blog-adjacent-ai-feature-positioning-zh-CN":30,"blog-related-ai-feature-positioning-zh-CN":65},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":12,"readingMinutes":13,"featured":14,"tags":15,"category":19,"seoSettings":29},59,"ai-feature-positioning","AI 功能的产品定位","把大模型当成万能助手，通常会做出没人用的功能。定位应该从具体任务开始。","\u003Cp>过去两年，几乎每个客户都会问能不能加 AI。多数时候我们建议先别急着加，而是找一个具体的、重复的、容错率高的任务，先在内部验证。\u003C\u002Fp>\n\u003Ch2>适合先做的三类任务\u003C\u002Fh2>\n\u003Cp>文本整理：把会议记录、工单描述转成结构化字段，人工只需校对。\u003C\u002Fp>\n\u003Cp>信息提取：从合同、发票、简历中抽取关键信息，减少重复录入。\u003C\u002Fp>\n\u003Cp>草稿生成：客服回复、产品描述、周报初稿，让用户从空白页开始变得容易。\u003C\u002Fp>\n\u003Ch2>三类要谨慎的场景\u003C\u002Fh2>\n\u003Cp>直接面向客户的自动答复，出错成本高，必须有兜底和人工接管。\u003C\u002Fp>\n\u003Cp>涉及金额计算和合规判断的环节，模型只能辅助，不能最终决定。\u003C\u002Fp>\n\u003Cp>没有明确评价标准的任务，无法判断效果好坏的，先不要做。\u003C\u002Fp>\n\u003Cp>AI 功能的价值不在技术先进，而在是否真的减少了某个岗位的重复劳动。找不到这个点，就先别做。\u003C\u002Fp>","","slate","佳益方圆团队","2026-06-29T10:57:00+08:00",1,false,[16,17,18],"AI","产品定位","落地",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},2,0,"product-thinking","产品思维","需求分析、用户体验与产品设计方法论，以及从业务问题到产品方案的思考过程。","lightbulb","blue","article",50,{},{"previous":31,"next":47},{"id":32,"slug":33,"title":34,"excerpt":35,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":36,"updatedAt":36,"readingMinutes":13,"featured":14,"tags":37,"category":41},39,"legacy-data-migration","数据迁移：先把旧系统的账算清","迁移失败的原因通常不是技术，而是没人说得清旧数据里到底有什么。","2026-07-01T10:57:00+08:00",[38,39,40],"数据迁移","老系统","项目实践",{"id":13,"parentId":21,"slug":42,"name":43,"description":44,"icon":45,"cover":9,"tone":26,"kind":27,"sortOrder":46,"count":21},"engineering","技术专栏","架构设计、性能优化、AI 集成与跨端方案等一线技术实践，由研发团队持续分享。","cpu",60,{"id":48,"slug":49,"title":50,"excerpt":51,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":53,"updatedAt":53,"readingMinutes":13,"featured":14,"tags":54,"category":58},79,"acceptance-dispute-retro","验收扯皮复盘：标准不清的代价","系统做完了，客户说“不是我们想要的”。所有争议最后都回到同一句话：当初没说清楚。","indigo","2026-06-27T10:57:00+08:00",[55,56,57],"复盘","验收","需求管理",{"id":59,"parentId":21,"slug":60,"name":61,"description":62,"icon":63,"cover":9,"tone":26,"kind":27,"sortOrder":64,"count":21},3,"project-retrospective","项目复盘","从 0 到 1 的真实项目记录，完整呈现问题、方案、踩坑经验与最终结果。","clipboard-check",40,[66,76,86],{"id":28,"slug":67,"title":68,"excerpt":69,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":70,"updatedAt":70,"readingMinutes":13,"featured":14,"tags":71,"category":75},"grading-requirement-confidence","需求的真实度分级","把需求当成事实来做，是项目延期最常见的原因。需求其实有可信度高低之分。","2026-10-15T09:00:00+08:00",[72,73,74],"需求","产品方法","风险管理",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":20,"slug":77,"title":78,"excerpt":79,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":80,"updatedAt":81,"readingMinutes":20,"featured":14,"tags":82,"category":85},"vertical-product-rules","垂直行业产品的分水岭：把行业默认规则写进系统","垂直不是换一个行业名字。真正的门槛，是能否理解并承接那些从业者习以为常的默认规则。","2026-10-09T10:00:00+08:00","2026-10-18T15:58:14.661+08:00",[83,84],"行业产品","产品设计",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":87,"slug":88,"title":89,"excerpt":90,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":91,"updatedAt":91,"readingMinutes":13,"featured":14,"tags":92,"category":94},51,"mvp-boundary","MVP 的边界怎么划","最小可用不是功能最少，而是能完整跑通一条业务闭环。","2026-10-03T10:13:00+08:00",[93,73,72],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21}]