腾讯云开发者
订阅
腾讯云官方社区公众号,汇聚技术开发者群体,分享技术干货,打造技术影响力交流社区。
腾讯云开发者微信公众号二维码
关注该公众号

会员可查看最新的全部文章

^__^ 1 / 23
AI是开发忠实的合作伙伴:知识渊博(训练内化各类通用知识)、有一定的逻辑推理能力、效率惊人,但同时确定性不太好(概率本质,幻觉)。我们大多数需求追求的是确定性的交付结果,所以要采用一些合适方法,让AI扬长避短,在提效同时,保证结果稳定。实践下来,PDCA是个高效方法:戴明的 PDCA(也称“戴明环”)是持续改进的闭环方法。定义:PDCA = Plan(计划)- Do(执行)- Check(检查)- Act(处理/标准化),循环往复实现持续改进。目的:以数据驱动、低风险的小规模试验验证改进行动,沉淀为标准,再进入下一轮升级。需求交付中,把目标拆到尽可能小的确定的独立任务,明确达成路径,再基于每个小任务和 AI 结对编程,如此循环,将AI的黑魔法变成稳定可靠的生产力。 Plan是单次循环中最重要的一步,类似CoT,但由人主导规划,AI辅助,以保证达成目标路径的确定性。在每个循环中,通过D-C循环来确保符合预期。 Act是长期改善的关键:从本次需求视角看,可以对不符合预期的结果调整指令、计划、上下文。从全局视角看,可以识别和沉淀规则,分析模式抽象组件(例如:由专用Agent承载),持续改善开发环境。典型案例:快速验证 Plan:拆 MVP 聚焦核心产品假设,拆解MVP,再基于MVP进一步拆解任务。 Check:收集反馈小任务粒度,自己体验是否能跑通,体验是否顺畅。 MVP粒度,找产品经理或典型客户体验,收集反馈结果。 Act:产品迭代基于反馈调整方案或者产品方向,并沉淀可复用的能力,为下轮迭代做准备。提示词工程本质是好好说话,可以通过套模板的结构化表达组织,随着大模型推理能力的快速进化,提示词的技巧性会被逐渐抹平,最终还是会回归到上下文背景+目标的核心诉求。 AI深入应用,逐步带来业务开发的范式演进,对人的要求也会变化。从经验驱动到知识工程,业务开发,逐渐演进为人 + Agent矩阵的协同生产。开发人员应当持续投入建设知识工程,在日常研发过程中逐步构建场景化 AI Agent,并持续提升稳定性,大步迈向 100x 大 AI 时代。延展阅读:与Cursor结对编程,掌握这个方法效率起飞!
^__^ 1 / 16
没有业务的技术,犹如无源之水无根之木。成为技术大牛的前提,是搞懂业务的本质。 业务:一个组织、公司或个人所从事的商业活动、服务或工作,相应的流程和规则。 业务相关活动所涉及的问题范围,即问题域,通常也是公司为其客户提供的服务。 产品,通常是指对应的业务背景下为相关问题域提供的解决方案,即为用户/目标组织所提供的系统或服务。 产品是对解决方案的包装,支撑起解决方案的实现即系统(业务系统)。 业务开发,冠以“业务”前缀,要的是在技术通识的基础上,更要熟悉业务。 业务开发团队,要承接并交付出“好”的业务系统,挑战在两点: 从0到1阶段:洞察用户痛点,解决核心用户问题。 1到100阶段:业务系统能轻松、高质量地动态进化,在不断发展中支持业务攻城略地。 洞察痛点:本质在于理解业务,能够定义边界/聚焦重点 【面向需求】要开发什么样的产品?【面向业务】为什么要开发这个产品?要解决什么问题,达成什么目标? 动态进化:本质依托于业务系统的设计和实现 【面向设计】如何做才能契合业务形态应对变化、减少制约以更好的达成目标? 对于技术要承载的业务,要跳出单一代码视角,从两种视角拆开看: 问题空间:即问题域,探讨关注有什么问题要解决,存在什么痛点要消除,也即需求; 解空间:也称解决方案域,考虑有哪些方案去解决问题;最终用哪个方案做到了,称为实现。 提问题比解决问题更重要。 初识业务,或者成熟业务上扩展出新需求,需要主动思考: 业务现状,为谁服务?全景如何,上下游如何合作?核心价值,利润来源?最重要待解决问题?…… 有全局认识,才能建立足够的判断力,帮助高效对接/厘清业务,放大价值贡献。 业务建模是一个体系化主题,不同的场景有其合适的用法。只有当有更多角色直接参与,并有更多不同业务信息由该系统处理时,业务建模才会增加更多价值。例如,纯技术领域的问题中,与业务无关,可以无须业务建模,你的代码和数据结构就是你的模型抽象 当 LLM 掀起巨浪,Prompt Engineering的本质也是“如何理解业务并结构化陈述业务需求”,这与业务建模方法为业务开发赋予的理解问题域能力正好契合,“声明式的方法+结构化抽象并逐步分解问题”的思维不会过时,AI时代甚至有机会赋予业务开发新价值。 延展阅读:天天写业务代码,如何破局业务开发的本质? 各位彦祖亦菲,你对本篇命题的答案是?