最新文章

test opus

What Are Server Functions? Basic Concepts Server Functions are asynchronous functions that run on the server side. Since clients need to invoke them via network requests, these functions must be asynchronous. This design allows clientside code to interact with the server just like calling ordinary async functions, without manually writing API routes or dealing with complex network communication logic. When used in the context of actions or mutations, they are also referred to as Server Actions. Server Actions Definition and Conventions By convention, Server Actions are asynchronous functions used in conjunction with startTransition. startTransition is a React API that marks certain updates as "nonurgent transitions," preventing them from blocking UI rendering. startTransition is triggered automatically in the following cases, with no need for manual invocation: When passed to a <form element via the action prop When passed to a <button element via the formAction prop Usage Example jsx // Define a server function 'use server' async function submitForm(formData) { const name = formData.get('name') // Process data on the server, e.g., write to a database await db.user.create({ data: { name } }) } // Use it in a client component export default function MyForm() { return ( // Pass the server function directly to the action prop <form action={submitForm} <input type="text" name="name" placeholder="Enter your name" / {/ Pass the server function to the formAction prop /} <button type="submit" formAction={submitForm} Submit </button </form ) } How It Works Single RoundTrip Optimization When an Action is triggered, Next.js can accomplish all of the following within a single server round trip: ✅ Execute serverside logic (e.g., database operations, file processing) ✅ Return the updated UI ✅ Deliver the latest data state This mechanism significantly reduces the number of network requests, offering superior performance compared to the traditional "request → response → fetch data again" pattern. Traditional pattern: Client → [Submit request] → Server → [Return result] → Client → [Fetch data again] → Server → [Return data] → Client Server Actions pattern: Client → [POST request] → Server → [Return updated UI + latest data] → Client Underlying HTTP Implementation Under the hood, Server Actions use the HTTP POST method — and only POST can trigger a call. This design aligns with HTTP semantic conventions: HTTP Method Semantics Can Trigger Server Actions GET Read / query data ❌ Not supported POST Submit / modify data ✅ Supported PUT Update data ❌ Not supported DELETE Delete data ❌ Not supported 💡 Why only POST? Semantically, a POST request means "submit data and produce side effects," which closely aligns with the nature of Server Actions (performing data mutation operations). Additionally, POST request bodies can safely carry form data, whereas GET request parameters are exposed in the URL — making GET unsuitable for transmitting sensitive information or large volumes of data. Summary of Key Advantages Feature Description Simplified Development No need to manually create API routes — invoke server logic directly within components Type Safety Supports endtoend TypeScript type inference Performance Optimization Data submission and UI updates completed in a single round trip 进增强 即使 JavaScript 未加载完成,表单提交仍可正常工作 安全性 服务器端代码不会暴露给客户端

zk
zk
·
70

从0到1搞懂AI全栈:我靠“一人公司”模式,搞定从老板到销售的所有活

一、OPC模式:一个AI高手,就是一整个团队 刚开始接触OPC的时候,我一度以为是“噱头”——一个人怎么可能搞定所有岗位?直到我亲自上手试了半个月(每天晚上8点学到11点,周末连肝2天),才发现:不是一个人硬扛所有活,而是用AI当“工具人”,调度各个AI能力,完成工作闭环。 简单说,OPC的核心就是“AI Engineering(Harness 工程)”,把AI当成自己的“虚拟团队”,你只需要做“总指挥”,负责定方向、调工具、控结果,剩下的脏活累活全交给AI。 我的真实角色转变:从“打工人”到“一人老板” 这半个月,我硬生生把自己逼成了“全能选手”,每个角色都靠AI辅助完成,分享下我的真实经历和实操细节,大家可以直接参考: 1. 老板(Project Owner):靠“灵感+AI”找需求 作为“老板”,第一步就是找需求——总不能瞎忙活吧?刚开始我想破脑袋,不知道做什么项目,后来用Claude帮我分析“当下高需求、低门槛的AI赛道”,结合我自己养宠物的经历,最终定了方向:狗语翻译器。 这里插个小细节:当时AI给了10个赛道建议,我排除了AI写作、AI绘画(竞争太激烈),最终选了宠物陪伴赛道——查了数据才知道,宠物陪伴市场居然是万亿规模!而且目前狗语翻译类产品要么功能单一,要么不准确,正好有机会切入。 ✅ 我的小技巧:用“需求+场景+痛点”prompt问AI,比如“帮我分析宠物陪伴赛道的潜在需求,重点是狗主人的核心痛点,给出3个可落地的项目方向”,AI会直接帮你梳理清楚,省去自己查资料的时间。 2. 产品经理(AI PM):让AI帮我梳理产品逻辑 定了狗语翻译器的方向,接下来就是做产品设计——作为小白,我完全不懂产品逻辑,怎么办?找AI当我的“产品助理”! 我给AI的prompt是:“我要做一款狗语翻译器,面向养犬人群,核心功能是通过声音识别狗狗的情绪、需求(比如饿了、想出门、生气),请帮我梳理产品核心功能、目标用户、落地路径,还要考虑数据来源”。 不到10分钟,AI就给了完整的产品逻辑,重点提炼了2点(也是我之前没想到的): 数据来源:收集不同品种狗狗的声音大数据(比如金毛、泰迪、哈士奇),按“场景(在家、出门)、情绪(开心、焦虑)、需求(进食、玩耍)”分类,喂给LLM训练; 核心亮点:不仅能翻译,还能给出对应解决方案(比如狗狗叫是因为焦虑,建议多陪伴、给玩具)。 这里踩了个小坑:刚开始AI给的功能太复杂,包含了“狗狗健康监测”“社交功能”,后来我让AI“精简核心功能,优先落地最小可行产品(MVP)”,才梳理出清晰的逻辑——新手做产品,千万不要贪多! 3. 设计师(AI Designer):0基础搞定硬件+界面 产品逻辑定好了,接下来就是设计——硬件(比如佩戴在狗狗身上的手环)和软件界面(手机App),我连PS都不会,全靠AI救场! 硬件设计:用OpenAI生成手环设计图,prompt是“简约风格狗狗智能手环,小巧轻便,能收集声音,颜色是浅灰色,适合中小型犬,细节清晰,工业设计感”,生成了10张图,我选了最简洁的一款,还能直接发给工厂参考; 软件界面:用OpenAI,输入“狗语翻译器App界面,简约清新,主色调是浅蓝色,包含‘实时翻译’‘历史记录’‘狗狗档案’3个核心页面”,自动生成界面原型,还能直接修改细节。

从0到1搞懂AI全栈:我靠“一人公司”模式,搞定从老板到销售的所有活
kegimi
kegimi
·
162