这是一个创建于 83 天前的主题，其中的信息可能已经有所发展或是发生改变。
依稀记得在 gpt 渐入大众的视野时，和朋友闲聊一个话题----gpt 和人类最大的区别是什么？有位朋友提到了创造性，gpt 虽然可以在短时间内快速给出接近人类思维的答复，但是给出的方案是待考究且可能是过时的。在同等情况下，人类不仅会基于专业基础还会根据其他学识综合当前处境调整应对策略，给出意想不到的解决方案。而 gpt 只能根据预训练模型中被“喂养”的知识给出一堆耦合成的弱连贯性回复，这一点在提问范围模糊时更有体现。
但随着更多高级模型推出及用户使用次数提升，我们对 AI 工具(比如 Open AI,Kimi,Claude)的使用愈发上手，知道如何调整提问让它给出更精确的答案----我们只需要耐心把细节告诉 AI ，剩下的只需要等待、审视、根据上一轮答复微调提问。此刻我们不再是一个 Task Runner,而转变成了 Project Owner 。在 AI 降世之前，开发者们可能会因为写出一个复杂、抽象函数代码而沾沾自喜、自我陶醉在技术实现的世界里。而实现只是服务于功能运行，把关注点转移到架构设计、功能实用性，远比实现本身有更大的价值体现。受益的不仅是团队，更是产品及用户。
AI 成为了我们的左膀右臂，意味着不必再为了数个类似业务重复劳作。既然如此，跳出劳动者这个定位，尝试从责任人的角度看待事物，那能做的事情就不只是实现层面。而是关乎整个项目起草，mvp 版本，需求迭代。这个过程则是产品间（或者独立开发）与自身、用户（甲方）商讨，及内部讨论大胆描述天马行空的想法，脑海里不断模拟、创造出期望的画面、思索细节，直到敲定了某一条分支，然后召集职能人员对齐理解，并着手开发。过程中的讨论、描述都是创造、设计的艺术体现，这使得我们对项目的理解层次得到升华。
最后，AI 工具的面向群体愈发广泛，多数行业在熟练运用后都可以减少开发时的成本。请尝试着成为 AI 工具的 leader ，具体实现交给他们就行，然后全身心投入在需求分析、方案评审、可行性评估上，思路正确远比着手干来得重要且有意思。Project Owner 何尝不是产品经理，既然是产品, 则关乎设计，而设计便是艺术。
推荐阅读
● 「代码艺术家」不会被 AI 取代 ( https://lutaonan.com/blog/code-artist/)
● Software is Art ( https://danielnguyen.me/software-is-art-2)
但随着更多高级模型推出及用户使用次数提升，我们对 AI 工具(比如 Open AI,Kimi,Claude)的使用愈发上手，知道如何调整提问让它给出更精确的答案----我们只需要耐心把细节告诉 AI ，剩下的只需要等待、审视、根据上一轮答复微调提问。此刻我们不再是一个 Task Runner,而转变成了 Project Owner 。在 AI 降世之前，开发者们可能会因为写出一个复杂、抽象函数代码而沾沾自喜、自我陶醉在技术实现的世界里。而实现只是服务于功能运行，把关注点转移到架构设计、功能实用性，远比实现本身有更大的价值体现。受益的不仅是团队，更是产品及用户。
AI 成为了我们的左膀右臂，意味着不必再为了数个类似业务重复劳作。既然如此，跳出劳动者这个定位，尝试从责任人的角度看待事物，那能做的事情就不只是实现层面。而是关乎整个项目起草，mvp 版本，需求迭代。这个过程则是产品间（或者独立开发）与自身、用户（甲方）商讨，及内部讨论大胆描述天马行空的想法，脑海里不断模拟、创造出期望的画面、思索细节，直到敲定了某一条分支，然后召集职能人员对齐理解，并着手开发。过程中的讨论、描述都是创造、设计的艺术体现，这使得我们对项目的理解层次得到升华。
最后，AI 工具的面向群体愈发广泛，多数行业在熟练运用后都可以减少开发时的成本。请尝试着成为 AI 工具的 leader ，具体实现交给他们就行，然后全身心投入在需求分析、方案评审、可行性评估上，思路正确远比着手干来得重要且有意思。Project Owner 何尝不是产品经理，既然是产品, 则关乎设计，而设计便是艺术。
推荐阅读
● 「代码艺术家」不会被 AI 取代 ( https://lutaonan.com/blog/code-artist/)
● Software is Art ( https://danielnguyen.me/software-is-art-2)
1 条回复 • 2024-09-09 15:14:38 +08:00
 |
1
glcolof 83 天前
不管怎么说，以后劳动者更不重要了，社会资源更重要了
|
Select Language