另一个 D2C 智能化的难点是模型识别的结果最终如何用于生成代码，例如组件识别模型能识别组件的类别，但最终生成代码使用哪个组件库的组件、如何识别 UI 中的组件属性值这些问题，imgcook 的平台能力与智能还原技术分层架构具备解决这些问题的能力，未来会有更多的智能化方案用于生产环境。
后续我们会继续根据对 imgcook 的 D2C 智能化能力拆解，探索更多智能化解决方案，优化现有模型能力，建立算法工程闭环机制实现每一个模型的自我迭代，不断提高模型的泛化能力和线上识别准确度，辅助生成可维护性更高语义更强的前端代码。
最近，我花了一些时间，将其初步梳理出来，写成了这篇文章。
文章的内容涵盖了“需求管理、平台设计、产品验证、平台协同、人性对抗、跨界思维、挑战/成长”等7个方面，既有一些抽象的、方法层面的总结，也有很多真实的、有体感的案例。
只有这样，客户才愿意跟你多聊、深聊，只有这样，你才能捕获到有价值的信息。再加上，观察客户的具体行为和操作，就能捕捉到真实的需求，才能做到有所洞察。
于是，结束会议后，我们要求上楼到标注员工的办公区，具体看看情况。
当我们站在标注人员身后，仔细观察他们的操作、与他们深入交谈后，就有了新的发现。
换句话，也是手段和目的的问题——“浅层需求”往往只是手段，而“深层需求”才是目的。
举个例子，对于我们负责的金融视觉平台，有用户反馈“我需要模型报告”，即模型训练出来后，将一些“准确率、召回率、AUC之类”的指标，用图表的方式展示出来。
对于中台、平台产品来说，其实也是这样的，只不过用户遇到不爽的体验只能忍忍，因为使用你的产品来解决他的业务需求，这是他的本质工作。
而且，日后的运营活动也好做了，比如可以评比“十大研究员、十佳实验室”等等。
总之，在设计产品的术语体系，首先是“如无必要，勿增实体”，其次，要尽量借助大家脑海中已有的概念，而不是直接照搬技术实现，或者生造新的概念。
即使你在概念设计上下了功夫，也不能保证用户不会产生任何疑问。
因此，就需要设计“帮助体系”，做进一步的解释和阐述。
这里，并不是说让你写一份冗长的产品文档。文档应该写，但它不是重点，因为大部分人并不会仔细把产品文档读完才动手操作——他只有遇到问题，才有可能去查查手册。
