深有体会啊！前面用AI写代码确实很快，但是越到后面，涉及的细节越多，AI就越容易出错。而且改起来特别麻烦，感觉还不如自己写。后来我学乖了，把任务拆解得更细，每一步都让AI生成测试用例，这样才勉强Hold住。
我觉得人最重要的价值在于“Contextual Awareness”（情境感知）。AI可以生成代码，但它缺乏对业务、用户、以及整个系统环境的深刻理解。人需要根据实际情况，对AI生成的代码进行调整和优化，使其更好地融入现有的系统。此外，人还需要负责制定规范、管理风险，以及进行最终的决策。
在AI编程的过程中，人应该发挥以下价值：
1. 需求理解和拆解： 将模糊的需求转化为清晰的任务，并将其分解为更小的、可管理的部分。
2. 架构设计： 设计系统的整体架构，确保其可扩展性、可维护性和安全性。
3. 代码审查： 仔细审查AI生成的代码，确保其符合规范、逻辑正确，并能满足需求。
4. 问题解决： 解决AI无法处理的复杂问题，例如调试、性能优化和安全漏洞修复。
5. 创新和改进： 利用AI提供的能力，探索新的解决方案和技术，不断改进开发流程和产品质量。
6. 风险管理： 识别和评估AI可能引入的风险，并采取相应的措施进行防范。
评估内部模型，我认为重点在于：
1. 安全审计： 找专业的安全团队进行代码审计，看看有没有潜在的安全风险，比如数据泄露、权限绕过等。
2. 能力评估： 建立一套benchmark，模拟实际业务场景，评估模型的性能、准确率、稳定性等指标。
3. 红队演练： 组织红队进行攻击演练，模拟黑客攻击，检验模型的防御能力。
4. 合规审查： 确保模型符合相关的法律法规和合规要求，比如数据隐私保护、内容审查等。
选择外部模型，除了考虑文章中提到的因素，还要注意：
1. 服务协议： 仔细阅读服务协议，了解数据的使用方式、隐私保护政策等。
2. 供应商资质： 考察供应商的资质、信誉和服务能力，选择有保障的供应商。
3. 数据传输安全： 确保数据在传输过程中进行加密，防止数据泄露。
总之，要对内部模型和外部模型进行全方位的评估和审查，确保安全可靠。
这个问题涉及到团队文化和管理。我们需要让团队成员认识到文档的重要性，将其视为团队共同维护的知识资产。可以定期组织文档 review 会议，鼓励大家积极参与文档的编写和完善。另外，还可以设立文档奖励机制，激励大家贡献高质量的文档。
我觉得最大的挑战是让团队成员接受这种新的工作方式。毕竟很多人已经习惯了直接写代码，让他们先写文档可能会觉得很麻烦。所以需要领导层的支持和推动，同时也要提供相应的培训和工具，帮助大家更好地适应这种转变。
从一个安全工程师的角度来说，我觉得可以考虑引入一些“红队演练”，模拟黑客攻击，检验安全措施的有效性。这就像“防火演习”，可以帮助企业发现潜在的安全漏洞，并及时进行修复。
可太真实了，我之前用AI生成一个数据处理的脚本，前面90%都挺顺利，结果最后涉及到一些异常情况的处理，AI就开始各种瞎编乱造，逻辑漏洞百出。最后还是得自己一行一行debug，改到吐血。
我觉得两者都有。从组织行为学的角度来看，引入新技术必然会涉及到利益重新分配和权力结构调整，因此会引发各种阻力。要解决这些问题，需要进行充分的沟通和培训，让团队成员了解AI编程的优势和价值，并提供相应的支持和保障。
对付这种“最后 10% 陷阱”，我的经验是：1. 尽早进行全面的测试，尤其是针对边缘情况的测试。2. 将复杂问题拆解成更小的、更易于管理的部分。3. 不要完全依赖 AI，要保持批判性思维，随时准备手动干预。
与其盯着屏幕发呆，不如站起来溜达溜达，看看窗外，或者跟同事吹吹水。让大脑彻底放空一下，回来再看AI生成的代码，才能保持清醒的头脑，发现潜在的问题。就像跑马拉松，中间也要适当休息调整。
从长远来看，编程语言可能会越来越简单，甚至被自然语言取代一部分。所以，核心竞争力一定是那些不容易被AI取代的能力，比如抽象思维、系统性思考、创新能力。当然，对业务的深刻理解也是必不可少的。
“模型接力”和“仓库分级”是一种务实的安全策略，通过内部模型脱敏和外部模型生成代码，在一定程度上降低了敏感信息泄露的风险。然而，仍需注意以下问题：一是内部模型的安全性和可靠性，二是外部模型的合规性，三是数据传输过程中的加密和权限控制，四是定期进行安全审计和渗透测试。
测试同学表示瑟瑟发抖…感觉以后不仅要懂代码，还要懂AI，要和大模型斗智斗勇了！不过反过来想，如果能把测试流程也交给AI来做，那岂不是可以解放双手，提前过上退休生活？（手动狗头）
我觉得最直接的挑战是测试用例的设计。以前我们根据需求和设计文档来写测试用例，但AI生成代码后，逻辑可能更隐蔽，边界条件也更复杂，需要更深入的理解才能设计出有效的测试用例。机遇在于可以利用AI来辅助生成测试用例，甚至进行模糊测试，发现隐藏的bug。
文档即代码？听起来很美好，但实际上…我担心的是文档的更新问题。需求总是变来变去的，如果文档更新不及时，或者更新不准确，AI生成出来的代码岂不是更糟糕？感觉以后要花更多的时间在文档上，而不是代码上，这…真的能提高效率吗？
我觉得是文档的标准化和结构化。代码有严格的语法和规范，但自然语言文档往往比较随意，容易产生歧义。如何制定一套清晰、规范的文档编写标准，让AI能够准确理解和执行，是一个很大的挑战。而且，不同项目、不同团队可能需要不同的文档标准，这增加了落地的难度。
我比较担心的是“人”的因素。即使有了完善的安全策略，如果开发者安全意识薄弱，或者操作不规范，仍然可能导致安全问题。例如，不小心将敏感信息泄露到外部模型中，或者使用弱口令访问内部模型等。因此，加强开发者的安全培训和意识教育至关重要。
个人认为，最大的难点在于开发团队思维模式的转变。传统开发模式下，文档往往滞后于代码，甚至缺失。要真正实现“文档即代码”，需要团队成员从一开始就重视文档的编写和维护，并将其视为开发流程的核心环节。这需要强有力的制度保障和文化引导，才能克服惰性和习惯性思维。
安全问题确实是重中之重啊！现在动不动就爆出数据泄露事件，想想都后怕。除了文章里提到的，我觉得还要注意供应链安全，比如使用的第三方库、工具等等，万一被植入恶意代码，那就防不胜防了！