当H5应用'跑店通'因定位不准导致门店显示不全，一场与AI开发工具的拉锯战就此展开。作者通过增加搜索关键词而非更换地图API的优化路径，揭示了AI辅助开发中'慢即是快'的协作哲学。本文深度复盘了与AI斗智斗勇的一日攻坚，提炼出单任务拆解、明确需求边界、结果可视化验证三大提效心法。

今天上午9点，准时坐在了书桌前，开启了一天的工作。计划是针对我之前做的H5应用【跑店通】做一次功能优化。

需求是昨天收到的，试用后反馈说可能是定位不准，导致周边的实体门店显示不全。因为这直接影响到应用的使用体验，所以今天优先把这个问题给优化掉。

借着今天这个应用问题修复的事情，又把之前做产品经理的需求分析和解决方案工作流程走了一遍。

先是需求分析，用户反馈的是定位不准，导致我的应用搜索的附近门店不全。

这是一个用户需求，没问题。

接下来就是针对这个用户需求，拆解并找到性价比高的解决方案的过程。

因为我用的是百度秒哒，所以需要用到实体店的地理位置信息POI，毫无疑问对接的是百度地图。

正常来说，我的应用直接调取百度地图的API，所以位置精度主要取决于百度地图，第一反馈可能是需要更换地图。

但是如果更换地图的话很可能会涉及架构调整，成本较高，而且不一定能从根本上解决信息覆盖不全的问题，因为别的地图也有可能会出现类似问题。

接下来，是考虑会不会是因为代码或者集成调用问题，但因为代码是AI写的，所以和应用本身的代码质量应该没有多大关系。

接着，我想到我之前给AI指令写查询数据逻辑时，给到搜索门店的关键词只有3个，就很可能是因为搜索关键词太少，所以搜索返回的门店就少。

所以我意识到，应该从另一方面来优化这个问题，就是增加更多的关键词来召回更多的实体门店，然后展示在我的页面。

最终考虑到这个方案具备拓展性，而且性价比较高，于是我整理了具体的解决方案，包括增加更多的关键词，以及召回数据后信息整合去重等关键逻辑，整理提示词发给开发工具帮我优化。

整个过程体验来看，目前的AI开发工具十分考验使用者的耐心，稍有不慎就给你整跑偏，或者引出新的问题，更甚的时候耍老油条，明明啥都没干却说已经完成。

因此基于这个需求延展出来的各种问题，又花费我一天时间跟它斗智斗勇。当然，在这期间我也总结出一些能提升开发效率的经验。

比如，每次只让AI做一件事情，不管是加需求还是改缺陷。这样做虽然看起来不如一股脑把问题和要求全抛给AI来做，但是整体效率却是最高的。

慢就是快。

与其让AI做多错多，不如拆分成小的功能点细细完善。虽然做的步骤多了，但是debug的时间却少了，开发体验也提高了。

再就是，每次都要明确输入需求或者问题描述。这样做主要是为了不让AI发散或者过度产品化导致加一些莫须有的功能点，保证自己的设计能保持一致性和连贯性。

针对要改版调整逻辑，可能涉及影响核心流程的，多加一些限制要求都不为过，比如“不要动xxx页面/功能，只需要做xxx”、“本次仅修复展示/数据问题，不新增功能、不调整现有逻辑”。

最后，要明确验证要求，即最后希望达成什么样的效果。写清楚修复后的可见状态，让AI知道修完之后，你应该看到什么，而不是“逻辑上没问题了”。

我们的语言逻辑和AI开发工具的理解逻辑是不太一样的。如果不给AI立一些原则，最后很可能是跟自己的想法背道而驰，而且会有做不完的debug。

今天坐在书桌前大几个小时，就为了这一个优化需求，已经能深刻理解之前的开发小伙伴了。

单这个小应用已经累计更新了40+小版本，我在这种零编码AI语言大模型加持的条件下都感觉挺费劲，之前纯编码开发的小伙伴们可真是不简单的。

最近投入到应用开发的时间有点多，所以今天把这个问题修复掉后，再完整迭代一版后就先放着，等再积累些问题反馈后再统一优化。

除了今天这个主线任务外，又简单跟进了一下亚马逊店铺的情况，目前的情况是有在出单，也有再扣款。库存还有600+，不知道年前能不能卖完，也不知道能不能过个好年。