ਕੰਪਿਊਟਰ ਦੀ ਵਰਤੋਂ ਕੀ ਹੈ ਅਤੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਕੰਪਿਊਟਰ ਦੀ ਵਰਤੋਂ ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਹੈ, ਜਿਸ ਦੇ ਪ੍ਰਭਾਵ ਵਿਆਪਕ ਹਨ: ਮਾਡਲਾਂ ਨੂੰ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਲਈ ਕਹਿਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਚਲਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹਾਂ—ਵੈੱਬਸਾਈਟਾਂ ਉੱਤੇ ਜਾਣਾ, ਫਾਰਮ ਭਰਨਾ, ਕਾਰਜ-ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਕਲਿੱਕ ਕਰਨਾ ਅਤੇ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਕੰਮ ਖ਼ੁਦਮੁਖਤਿਆਰੀ ਨਾਲ ਪੂਰੇ ਕਰਨਾ.
ਇਸ ਨਾਲ ਅਸਲ ਦੁਨੀਆ ਦੇ ਬਹੁਤ ਸਾਰੇ ਅਜਿਹੇ ਕੰਮ ਸੰਭਵ ਹੋ ਜਾਂਦੇ ਹਨ ਜੋ ਇਸ ਵੇਲੇ ਵੱਖ-ਵੱਖ ਇੰਟਰਫੇਸਾਂ ਵਿੱਚ ਵੰਡੇ ਹੋਏ ਹਨ, ਜਿਵੇਂ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਬੁਕਿੰਗ, ਈ-ਕਾਮਰਸ ਭੁਗਤਾਨ, ਕਈ ਪੜਾਵਾਂ ਵਾਲੀ ਯਾਤਰਾ ਯੋਜਨਾ ਅਤੇ ਉਹ ਪਿਛਲੇ ਦਫ਼ਤਰ ਦੇ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਜਿਨ੍ਹਾਂ ਲਈ ਕੋਈ ਸਾਫ਼ API ਵਿਕਲਪ ਨਹੀਂ ਹੈ. ਇਹ ਸਮੱਸਿਆਵਾਂ ਨਵੀਆਂ ਨਹੀਂ ਹਨ. ਨਵੀਂ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹੁਣ ਆਮ-ਉਦੇਸ਼ ਵਾਲੇ ਮਾਡਲਾਂ ਨਾਲ ਇਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਸੰਭਵ ਹੈ.
Anthropic ਅਤੇ OpenAI ਦੇ ਹਾਲੀਆ ਸਿਸਟਮਾਂ ਨੇ ਅਜਿਹੇ ਏਜੰਟ ਦਿਖਾਏ ਹਨ ਜੋ ਸਿਰਫ਼ ਕਾਰਵਾਈ ਹੀ ਨਹੀਂ ਕਰਦੇ, ਸਗੋਂ ਸਥਿਤੀ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਦੇ, ਗਲਤੀਆਂ ਤੋਂ ਉੱਭਰਦੇ ਅਤੇ ਮੌਕੇ ਉੱਤੇ ਕੰਮ-ਵਿਸ਼ੇਸ਼ ਹੱਲ ਬਣਾਉਂਦੇ ਹਨ. ਇਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਏਜੰਟਾਂ ਲਈ ਇੱਕ ਆਮ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਨ ਬਣ ਜਾਂਦਾ ਹੈ, ਪਰ ਤੁਰੰਤ ਇੱਕ ਡਿਜ਼ਾਈਨ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਇਸ ਵਾਤਾਵਰਨ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਮਾਡਲ ਲਈ ਉਪਲਬਧ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਸ਼ੁਰੂਆਤੀ ਸਿਸਟਮਾਂ ਨੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕਾਰਵਾਈਆਂ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ ਵਿੱਚ ਲਪੇਟ ਕੇ ਇਸ ਦਾ ਜਵਾਬ ਦਿੱਤਾ. ਜਿਵੇਂ ਅਸੀਂ ਇਸ ਲੇਖ ਵਿੱਚ ਦਲੀਲ ਦੇਵਾਂਗੇ, ਇਹ ਪਹੁੰਚ ਆਪਣੀਆਂ ਹੱਦਾਂ ਤੱਕ ਪਹੁੰਚ ਰਹੀ ਹੈ.
ਬ੍ਰਾਊਜ਼ਰ ਏਜੰਟ ਬਣਾਉਂਦੇ ਸਮੇਂ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਸਹਿਜ ਪ੍ਰਵਿਰਤੀ ਹੁੰਦੀ ਹੈ: ਮਾਡਲ ਉੱਤੇ ਬਹੁਤਾ ਭਰੋਸਾ ਨਾ ਕਰੋ.
ਇਸ ਲਈ ਅਸੀਂ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਰੈਪਰ ਵਿੱਚ ਲਪੇਟਦੇ ਹਾਂ. ਅਸੀਂ click, type, scroll, select ਅਤੇ read_text ਵਰਗੇ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਟੂਲ ਉਪਲਬਧ ਕਰਾਉਂਦੇ ਹਾਂ. ਅਸੀਂ ਦਸਤਾਵੇਜ਼ ਆਬਜੈਕਟ ਮਾਡਲ (DOM) ਨੂੰ ਸਰਲ ਬਣਾਉਂਦੇ ਹਾਂ. ਅਸੀਂ ਕਾਰਵਾਈਆਂ ਦਾ ਦਾਇਰਾ ਘਟਾਉਂਦੇ ਹਾਂ. ਅਸੀਂ ਆਪਣੇ ਬਣਾਏ ਅਮੂਰਤੀਕਰਨਾਂ ਰਾਹੀਂ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਨਿਯੰਤਰਣਯੋਗ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ.
ਇਹ ਸ਼ੁਰੂਆਤ ਲਈ ਵਾਜਬ ਪਹੁੰਚ ਹੈ. ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਇਹ ਲੰਮੇ ਸਮੇਂ ਲਈ ਗਲਤ ਆਰਕੀਟੈਕਚਰ ਵੀ ਸਾਬਤ ਹੋ ਰਹੀ ਹੈ.
ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ ਸੁਧਾਰ ਦੇ ਨਾਲ ਹੁਣ ਸੀਮਾ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਰਹੀ ਕਿ ਮਾਡਲ ਕੋਲ ਟੂਲਾਂ ਦੀ ਘਾਟ ਹੈ. ਸਮੱਸਿਆ ਇਹ ਵੀ ਹੈ ਕਿ ਅਸੀਂ ਉਸ ਨੂੰ ਅਜਿਹੇ ਅਮੂਰਤੀਕਰਨਾਂ ਰਾਹੀਂ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਰਹੇ ਹਾਂ ਜੋ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਦਾ ਬਹੁਤ ਕੁਝ ਹਟਾ ਦਿੰਦੇ ਹਨ. ਅਸੀਂ ਇੱਕ ਉਲਝੇ ਅਤੇ ਗਤੀਸ਼ੀਲ ਵਾਤਾਵਰਨ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਾਰਵਾਈ ਇੰਟਰਫੇਸ ਵਿੱਚ ਸਮੇਟ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਫਿਰ ਮਾਡਲ ਤੋਂ ਜਾਣਕਾਰੀ ਦੇ ਇਸ ਨੁਕਸਾਨ ਦੇ ਅੰਦਰ ਚੰਗਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ.
ਇਹ ਸਮਝੌਤਾ ਹੁਣ ਘੱਟ ਆਕਰਸ਼ਕ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ.
ਜਿਸ ਬਦਲਾਅ ਦੀ ਅਸੀਂ ਪੜਚੋਲ ਕਰ ਰਹੇ ਹਾਂ, ਉਸ ਦਾ ਵਰਣਨ ਸਰਲ ਹੈ ਪਰ ਉਸ ਦੇ ਨਤੀਜੇ ਮਹੱਤਵਪੂਰਨ ਹਨ. ਏਜੰਟ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕਾਰਵਾਈਆਂ ਚੁਣਨ ਵਾਲਾ ਮੰਨਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਉਸ ਨੂੰ ਸੀਮਤ ਰਨਟਾਈਮ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਗਰਾਮ ਸੰਸ਼ਲੇਸ਼ਕ ਮੰਨਦੇ ਹਾਂ.
ਮਾਡਲ ਹੁਣ ਬਹੁਤ ਸਮਰੱਥ ਹੋ ਗਏ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਡੇ ਅਮੂਰਤ ਸੁਰੱਖਿਆ-ਘੇਰਿਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹੀ. ਉਨ੍ਹਾਂ ਨੂੰ ਕੰਮ ਦੀ ਰਚਨਾ ਕਰਨ, ਉਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਅਤੇ ਟੀਚਾ ਹਾਸਲ ਹੋਣ ਤੱਕ ਦੁਹਰਾਉਣ ਲਈ ਕਾਰਵਾਈਆਂ ਦਾ ਪੂਰਾ ਦਾਇਰਾ ਚਾਹੀਦਾ ਹੈ.
ਇਹ ਲੇਖ ਇਸੇ ਬਦਲਾਅ ਬਾਰੇ ਹੈ—ਅਮੂਰਤੀਕਰਨ-ਭਾਰੀ ਬ੍ਰਾਊਜ਼ਰ ਸਵੈਚਾਲਨ ਤੋਂ ਸੀਮਤ ਕੰਪਿਊਟਰ ਵਰਤੋਂ ਤੱਕ—ਅਤੇ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਕਰਨ ਉੱਤੇ ਕੀ ਬਦਲਦਾ ਹੈ.
ਸਮੱਸਿਆ ਇਹ ਨਹੀਂ ਕਿ ਨਿਸ਼ਚਿਤ ਕਾਰਵਾਈ ਇੰਟਰਫੇਸ ਸਿਧਾਂਤਕ ਤੌਰ ਉੱਤੇ ਗਲਤ ਹਨ. ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਵੈੱਬ ਉਨ੍ਹਾਂ ਮੁਤਾਬਕ ਨਹੀਂ ਚੱਲਦਾ.
ਆਧੁਨਿਕ ਇੰਟਰਫੇਸ React, Vue ਅਤੇ Angular ਉੱਤੇ ਬਣੇ ਹਨ. ਇਨ੍ਹਾਂ ਵਿੱਚ ਅਸਮਕਾਲੀ ਸਥਿਤੀ ਅੱਪਡੇਟ, ਬਣਾਵਟੀ ਘਟਨਾ ਸਿਸਟਮ ਅਤੇ ਵੱਖਰੇ ਮੂਲ ਵਾਲੇ iframe ਵਿੱਚ ਸ਼ਾਮਲ ਤੀਜੀ-ਧਿਰ ਵਿਜਿਟ ਹੁੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੇ ਆਪਣੇ ਜੀਵਨ-ਚੱਕਰ ਹਨ. “ਇਸ ਇਨਪੁੱਟ ਵਿੱਚ ਲਿਖੋ” ਕਹਿਣ ਵਾਲਾ ਰੈਪਰ ਤਾਂ ਹੀ ਸਹੀ ਹੈ ਜੇ ਸਫ਼ਾ ਲਿਖਣ ਦੀ ਤੁਹਾਡੀ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਸਹਿਮਤ ਹੋਵੇ. ਬਹੁਤ ਸਾਰੇ ਸਫ਼ੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੇ. ਮੁੱਲ ਸਿੱਧਾ ਸੈੱਟ ਕਰਨ ਨਾਲ ਅਕਸਰ ਫਰੇਮਵਰਕ ਦੀ ਬਦਲਾਅ ਪਛਾਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਹੋ ਜਾਂਦੀ ਹੈ. ਇਨਪੁੱਟ ਭਰਿਆ ਹੋਇਆ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਪੁਸ਼ਟੀਕਰਨ ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ. ਫਾਰਮ ਕੰਮ ਨਹੀਂ ਕਰਦਾ.
ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਸੁਧਾਰ ਜੋੜ ਸਕਦੇ ਹੋ. ਤੁਸੀਂ React ਇਨਪੁੱਟਾਂ ਲਈ ਖ਼ਾਸ ਮਾਮਲੇ ਜੋੜ ਸਕਦੇ ਹੋ, ਫੋਕਸ ਤੋਂ ਬਾਅਦ blur ਘਟਨਾਵਾਂ ਭੇਜ ਸਕਦੇ ਹੋ ਅਤੇ ਸਥਿਤੀ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਨੈੱਟਵਰਕ ਦੇ ਨਿਸ਼ਕਿਰਿਆ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਸਕਦੇ ਹੋ. ਹਰ ਸੁਧਾਰ ਆਪਣੇ ਸਥਾਨਕ ਸੰਦਰਭ ਵਿੱਚ ਸਹੀ ਹੁੰਦਾ ਹੈ. ਪਰ ਇਕੱਠੇ ਹੋ ਕੇ ਇਹ ਅਜਿਹਾ ਸਿਸਟਮ ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਸ ਦੀ ਸੰਭਾਲ ਲਗਾਤਾਰ ਔਖੀ ਹੁੰਦੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜੋ ਤੁਹਾਡੀਆਂ ਪਹਿਲਾਂ ਦੇਖੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਹੋਰ ਵੀ ਵਿਸ਼ੇਸ਼ ਬਣਦਾ ਜਾਂਦਾ ਹੈ.
ਡੂੰਘੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੰਟਰੈਕਸ਼ਨਾਂ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਬਾਰੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਅਮੂਰਤੀਕਰਨ ਪਰਤ ਵਿੱਚ ਕੋਡਬੱਧ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਵੈੱਬ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਵੱਖਰੀਆਂ ਹਨ.
ਵੱਖਰੇ ਮੂਲ ਵਾਲੇ iframe ਵਿੱਚ Stripe ਜਾਂ Adyen ਰਾਹੀਂ ਸ਼ਾਮਲ ਭੁਗਤਾਨ ਫਾਰਮ ਉੱਤੇ ਵਿਚਾਰ ਕਰੋ. ਤੁਹਾਡਾ ਰੈਪਰ ਉਸ ਤੱਕ ਸਿੱਧਾ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਮੂਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ. ਤੁਹਾਡਾ read_text ਟੂਲ ਉਸ ਦੀ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਨਹੀਂ ਦੇਖ ਸਕਦਾ. ਤੁਹਾਡਾ type ਟੂਲ ਉਸ ਦੇ ਇਨਪੁੱਟਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ. ਰੈਪਰ-ਆਧਾਰਿਤ ਏਜੰਟ ਇੱਥੇ ਆ ਕੇ ਅਟਕ ਜਾਂਦਾ ਹੈ. ਅਮੂਰਤੀਕਰਨ ਮੁੱਖ ਦਸਤਾਵੇਜ਼ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ. ਅਸਲ ਕੰਮ ਅਜਿਹੀ ਥਾਂ ਉੱਤੇ ਹੈ ਜਿਸ ਨੂੰ ਅਮੂਰਤੀਕਰਨ ਦੇਖ ਨਹੀਂ ਸਕਦਾ.
ਇਸੇ ਤਰ੍ਹਾਂ ਦਾ ਬੇਮੇਲ ਘੱਟ ਸਪਸ਼ਟ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਵੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਫਰੇਮਵਰਕ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਲਟਕਵੀਂ ਸੂਚੀ ਸਿੱਧੇ ਕਲਿੱਕਾਂ ਉੱਤੇ ਬਿਲਕੁਲ ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਕਿਉਂਕਿ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਤੱਤ ਅਸਲ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੁੰਦਾ. ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਬਦਲਾਅ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕੀ-ਬੋਰਡ ਘਟਨਾਵਾਂ ਦੀ ਲੜੀ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ. ਬਾਹਰੋਂ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਕਲਿੱਕ ਕਰਨਯੋਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਅਮੂਰਤੀਕਰਨ ਕਹਿੰਦਾ ਹੈ, “ਕਲਿੱਕ ਕਰੋ.” ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ.
ਜਾਂ ਕਈ ਪੜਾਵਾਂ ਵਾਲੇ ਮਾਡਲ ਪ੍ਰਵਾਹ ਉੱਤੇ ਵਿਚਾਰ ਕਰੋ, ਜਿੱਥੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ DOM ਦੇ ਅੱਪਡੇਟ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਬਦਲਾਵਾਂ ਤੋਂ ਪਿੱਛੇ ਰਹਿੰਦੇ ਹਨ. ਅਗਲੀ ਸਹੀ ਕਾਰਵਾਈ ਅਜਿਹੇ ਸਥਿਤੀ ਬਦਲਾਅ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਰੈਪਰ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਤੱਤਾਂ ਵਿੱਚ ਹਾਲੇ ਪ੍ਰਗਟ ਨਹੀਂ ਹੋਇਆ. ਰੈਪਰ-ਆਧਾਰਿਤ ਏਜੰਟ ਬਹੁਤ ਜਲਦੀ ਕਾਰਵਾਈ ਕਰ ਬੈਠਦਾ ਹੈ ਜਾਂ ਪੁਰਾਣੀ ਸਥਿਤੀ ਪੜ੍ਹਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਸਿਸਟਮ ਦੇ ਅਧੂਰੇ ਦ੍ਰਿਸ਼ ਉੱਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ.
ਹਰ ਮਾਮਲੇ ਵਿੱਚ ਅਮੂਰਤੀਕਰਨ ਉਹ ਸੰਕੇਤ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਏਜੰਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜ ਹੁੰਦੀ ਹੈ.
ਹੇਠਲੇ ਪੱਧਰ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਮਾਡਲ—ਚਾਲੂ DOM ਦੀ ਜਾਂਚ ਕਰਕੇ, ਫਰੇਮ ਦੀਆਂ ਹੱਦਾਂ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਕੇ ਅਤੇ ਉਸ ਖ਼ਾਸ ਸਤਹ ਲਈ ਇੰਟਰੈਕਸ਼ਨ ਲੜੀ ਤਿਆਰ ਕਰਕੇ—ਇਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ. ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ ਮਾਡਲ ਸੁਭਾਵਿਕ ਤੌਰ ਉੱਤੇ ਵਧੇਰੇ ਹੁਸ਼ਿਆਰ ਹੈ. ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਸ ਕੋਲ ਉਸ ਜਾਣਕਾਰੀ ਦੀ ਪਹੁੰਚ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹਟਾ ਦਿੱਤੀ ਗਈ ਸੀ.
ਜਿਸ ਬਦਲਾਅ ਵੱਲ ਅਸੀਂ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ, ਉਸ ਦਾ ਵਰਣਨ ਸਰਲ ਹੈ: ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕਾਰਵਾਈਆਂ ਵਿੱਚੋਂ ਚੋਣ ਕਰਨ ਲਈ ਕਹਿਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਉਸ ਨੂੰ ਹੇਠਲੇ ਪੱਧਰ ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਤਹ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਉਸ ਸਤਹ ਨੂੰ ਅਮੂਰਤੀਕਰਨ ਡਿਜ਼ਾਈਨ ਦੀ ਬਜਾਏ ਰਨਟਾਈਮ ਨੀਤੀ ਰਾਹੀਂ ਸੀਮਤ ਕਰਦੇ ਹਾਂ.
ਇਹ ਡਿਜ਼ਾਈਨ ਚੋਣ ਉਦਯੋਗ ਵਿੱਚ ਹੋ ਰਹੇ ਵਿਆਪਕ ਬਦਲਾਅ ਤੋਂ ਉਪਜੀ ਹੈ, ਜੋ ਹੇਠਲੇ ਪੱਧਰ ਦੇ ਮੁੱਢਲੇ ਟੂਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਲੱਗਾ ਹੈ. ਇਹ ਟੂਲ ਏਜੰਟ ਦੀ ਰਨਟਾਈਮ ਉੱਤੇ ਸੁਧਾਰ ਕਰਨ ਅਤੇ ਉੱਚ-ਗੁਣਵੱਤਾ ਕੋਡ ਬਣਾਉਣ ਦੀ ਅੰਦਰੂਨੀ ਸਮਰੱਥਾ ਦਾ ਲਾਭ ਲੈਂਦੇ ਹਨ, ਜਦਕਿ ਸਖ਼ਤ ਕੋਡਬੱਧ ਖ਼ਾਸ ਟੂਲ ਮਜ਼ਬੂਤ ਤਾਂ ਹੁੰਦੇ ਹਨ ਪਰ ਮਾਡਲ ਤੋਂ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਨਾਂ ਮੁਤਾਬਕ ਢਲਣ ਦੀ ਸਮਰੱਥਾ ਖੋਹ ਲੈਂਦੇ ਹਨ.
ਕਈ ਵਿਕਾਸਕਾਰਾਂ ਦੇ ਟੂਲ-ਸੰਗ੍ਰਹਿ ਵਿੱਚ ਮੁੱਖ ਚੋਣ ਵਜੋਂ Claude Code ਦੀ ਸਫਲਤਾ ਅਤੇ ਟਰਮੀਨਲ-ਆਧਾਰਿਤ ਏਜੰਟਾਂ ਵੱਲ ਉਦਯੋਗ ਦੇ ਵਿਆਪਕ ਰੁਝਾਨ ਉੱਤੇ ਵਿਚਾਰ ਕਰੋ. Claude Code ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਲਾਭ ਖ਼ੁਦ ਮਾਡਲ ਨਹੀਂ, ਸਗੋਂ ਹੇਠਲੇ ਪੱਧਰ ਦਾ ਜਾਂਚ-ਢਾਂਚਾ ਹੈ. ਮਾਡਲ ਨੂੰ ਘੱਟ, ਵਧੇਰੇ ਮਾਡਿਊਲਰ ਅਤੇ ਹੇਠਲੇ ਪੱਧਰ ਦੇ ਟੂਲ ਦੇਣਾ—ਭਾਵ. ਟਰਮੀਨਲ—ਟੂਲ ਕਾਲ ਕਰਨ ਵਿੱਚ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਦਿੰਦਾ ਹੈ. ਇਸ ਦਾ ਮੁੱਖ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਏਜੰਟ ਸੰਦਰਭ ਸੀਮਾ ਨੂੰ ਬੇਲੋੜਾ ਭਰਨ ਵਾਲੇ ਸਧਾਰਨੀਕ੍ਰਿਤ ਟੂਲ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਮੌਜੂਦਾ ਕੰਮ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸ ਲਈ ਵਿਸ਼ੇਸ਼ ਸਕ੍ਰਿਪਟਾਂ ਬਣਾ ਸਕਦਾ ਹੈ.
ਬ੍ਰਾਊਜ਼ਰ ਸਵੈਚਾਲਨ ਲਈ ਅਮਲ ਵਿੱਚ ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਹਰ ਚੀਜ਼ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਬਣੀਆਂ ਨਿਸ਼ਚਿਤ ਕਾਰਵਾਈਆਂ ਨਾਲ ਜੋੜਨ ਦੀ ਬਜਾਏ, ਮਾਡਲ ਚਾਲੂ ਸਫ਼ੇ ਦੀ ਸਥਿਤੀ ਸਿੱਧੀ ਜਾਂਚ ਸਕਦਾ ਹੈ, ਫਰੇਮਾਂ ਵਿੱਚ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਇੰਟਰਫੇਸ ਲਈ ਵਿਸ਼ੇਸ਼ ਇੰਟਰੈਕਸ਼ਨ ਕੋਡ ਬਣਾ ਸਕਦਾ ਹੈ.
ਮਾਡਲ ਚੋਣਕਾਰ ਵਾਂਗ ਘੱਟ ਅਤੇ ਰਨਟਾਈਮ ਲੇਖਕ ਵਾਂਗ ਵੱਧ ਵਿਹਾਰ ਕਰਦਾ ਹੈ. ਉਹ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਇੰਟਰਫੇਸ ਬਾਰੇ ਰੀਜ਼ਨਿੰਗ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਖ਼ਾਸ ਸਥਿਤੀ ਲਈ ਇੰਟਰੈਕਸ਼ਨ ਤਰਕ ਤਿਆਰ ਕਰਦਾ ਹੈ. ਉਹ ਕਈ ਪੜਾਵਾਂ ਵਾਲੀਆਂ ਲੜੀਆਂ ਬਣਾ ਸਕਦਾ ਹੈ, ਅਸਧਾਰਨ ਪ੍ਰਵਾਹਾਂ ਮੁਤਾਬਕ ਢਲ ਸਕਦਾ ਹੈ ਅਤੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ. ਜਦੋਂ ਕੋਈ ਕਾਰਵਾਈ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਮਾਡਲ ਅੰਦਰੂਨੀ ਗਲਤੀ ਦੇਖ ਕੇ ਆਪਣੇ ਆਪ ਸੁਧਾਰ ਕਰਦਾ ਹੈ. ਇਹ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਅਤੇ ਵਧੇਰੇ ਜੋਖਮ ਭਰਿਆ ਹੈ—ਪਰ ਸਮੱਸਿਆ ਦੇ ਅਸਲ ਰੂਪ ਦੇ ਕਿਤੇ ਨੇੜੇ ਹੈ.
ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਅਮੂਰਤੀਕਰਨ ਪਰਤ ਹਟਾਉਣ ਨਾਲ ਸਿਸਟਮ ਘੱਟ ਅਨੁਸ਼ਾਸਿਤ ਨਹੀਂ ਹੁੰਦਾ. ਇਸ ਨਾਲ ਅਨੁਸ਼ਾਸਨ ਦੀ ਥਾਂ ਬਦਲ ਜਾਂਦੀ ਹੈ.
ਜੋ ਕੰਮ ਪਹਿਲਾਂ ਰੈਪਰ ਡਿਜ਼ਾਈਨ ਅਤੇ ਅਸਧਾਰਨ ਸਥਿਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਵਿੱਚ ਹੁੰਦਾ ਸੀ, ਉਹ ਹੁਣ ਤਿੰਨ ਥਾਵਾਂ ਉੱਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ: ਪ੍ਰੌਂਪਟ ਵਿੱਚ, ਜੋ ਸੰਚਾਲਨ ਸਿਖਲਾਈ ਦਾ ਰੂਪ ਬਣ ਜਾਂਦਾ ਹੈ; ਰਨਟਾਈਮ ਵਿੱਚ, ਜੋ ਨੈਵੀਗੇਸ਼ਨ ਦੇ ਦਾਇਰੇ, ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਦੇ ਵਿਹਾਰ ਵਰਗੀਆਂ ਹੱਦਾਂ ਲਾਗੂ ਕਰਦਾ ਹੈ; ਅਤੇ ਮੁਲਾਂਕਣ ਪਰਤ ਵਿੱਚ, ਜੋ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਜਾਂਚਦੀ ਕਿ ਕੰਮ ਸਫਲ ਹੋਇਆ ਜਾਂ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਵੀ ਕਿ ਵਿਚਕਾਰਲੇ ਪੜਾਅ ਸਹੀ ਸਨ ਜਾਂ ਨਹੀਂ. ਨਾਜ਼ੁਕ ਅਮੂਰਤੀਕਰਨ ਘੱਟ. ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸਿਸਟਮ ਵਧੇਰੇ ਮਜ਼ਬੂਤ.
ਇਸ ਬਦਲਾਅ ਦਾ ਇੱਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਸਮੁੱਚੇ ਸਿਸਟਮ ਦੀ ਸਮਰੱਥਾ ਵਧਣ ਦੇ ਬਾਵਜੂਦ ਉਤਪਾਦ ਦਾ ਕੋਡ ਅਕਸਰ ਸਰਲ ਹੋ ਜਾਂਦਾ ਹੈ. ਇੰਟਰੈਕਸ਼ਨ ਪੈਟਰਨਾਂ ਨੂੰ ਮੁੜ ਵਰਤਣਯੋਗ ਰੈਪਰਾਂ ਵਜੋਂ ਕੋਡਬੱਧ ਕਰਨ ਦੀ ਬਜਾਏ, ਏਜੰਟ ਰਨਟਾਈਮ ਵੇਲੇ ਵਿਹਾਰ ਤਿਆਰ ਕਰਦਾ ਹੈ. ਖ਼ਾਸ ਟੂਲਾਂ ਅਤੇ ਅਸਧਾਰਨ ਸਥਿਤੀਆਂ ਲਈ ਤਰਕ ਦਾ ਦਾਇਰਾ ਲਗਾਤਾਰ ਵਧਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕੁਝ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮੁੱਢਲੇ ਸਾਧਨਾਂ ਅਤੇ ਇੱਕ ਸੀਮਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਨ ਨੂੰ ਸੰਭਾਲਦੇ ਹੋ.
ਇਸ ਨਾਲ ਸਿਸਟਮ ਦੇ ਸਧਾਰਨੀਕਰਨ ਦਾ ਢੰਗ ਵੀ ਬਦਲ ਜਾਂਦਾ ਹੈ. ਰੈਪਰ-ਆਧਾਰਿਤ ਏਜੰਟ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਲਈ ਚੰਗਾ ਸਧਾਰਨੀਕਰਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਪਹਿਲਾਂ ਬਣਾਏ ਰੈਪਰਾਂ ਵਰਗੇ ਹੋਣ. ਸੀਮਤ ਰਨਟਾਈਮ ਵਾਲਾ ਏਜੰਟ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਲਈ ਸਧਾਰਨੀਕਰਨ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਆਧਾਰ ਸਾਂਝਾ ਹੋਵੇ, ਭਾਵੇਂ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਇੰਟਰਫੇਸ ਵੱਖਰਾ ਹੋਵੇ.
ਮਿਸਾਲ ਵਜੋਂ, ਖੋਜ ਫਾਰਮ, ਬੁਕਿੰਗ ਪ੍ਰਵਾਹ ਜਾਂ ਸੈਟਿੰਗਾਂ ਦੇ ਸਫ਼ੇ ਨਾਲ ਇੰਟਰੈਕਸ਼ਨ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਦੇ ਪੱਧਰ ਉੱਤੇ ਬਿਲਕੁਲ ਵੱਖਰਾ ਦਿਖ ਸਕਦਾ ਹੈ. ਪਰ ਅੰਦਰੂਨੀ ਪੱਧਰ ਉੱਤੇ ਇਨ੍ਹਾਂ ਦੇ ਪੈਟਰਨ ਸਾਂਝੇ ਹਨ: ਸਥਿਤੀ ਪੜ੍ਹਨਾ, ਘਟਨਾਵਾਂ ਸ਼ੁਰੂ ਕਰਨਾ, ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਅਤੇ ਅਸਮਕਾਲੀ ਅੱਪਡੇਟ ਸੰਭਾਲਣਾ. ਉਸ ਪੱਧਰ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਕੰਮਾਂ ਵਿੱਚ ਆਪਣੀ ਸਮਰੱਥਾ ਵਧੇਰੇ ਸੁਭਾਵਿਕ ਢੰਗ ਨਾਲ ਵਰਤ ਲੈਂਦਾ ਹੈ.
ਮੁੜ ਵਰਤਣਯੋਗ ਹਿੱਸਾ ਕਾਰਵਾਈਆਂ ਦੀ ਸੂਚੀ ਨਹੀਂ ਹੈ. ਇਹ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ, ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕਾਰਵਾਈ ਕਰਨ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਮਾਡਲ ਦੀ ਸਮਰੱਥਾ ਹੈ.
ਇਸ ਕੰਮ ਤੋਂ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਸਬਕ ਇਹ ਹੈ ਕਿ ਭਰੋਸੇਯੋਗਤਾ ਮਾਡਲ ਨੂੰ ਹੋਰ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਦੇਣ ਨਾਲ ਨਹੀਂ ਆਉਂਦੀ. ਇਹ ਅਕਸਰ ਉਸ ਨੂੰ ਘੱਟ ਪਰ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮੁੱਢਲੇ ਸਾਧਨ ਦੇਣ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੀਮਤ ਕਰਨ ਨਾਲ ਆਉਂਦੀ ਹੈ. ਹੱਦੋਂ ਵੱਧ ਸਹਾਇਤਾ ਕਿਸੇ ਕੰਮ ਨੂੰ ਕਰਨ ਦੇ ਢੰਗ ਬਾਰੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਪੱਕਾ ਕਰ ਦਿੰਦੀ ਹੈ. ਪਾਬੰਦੀਆਂ ਸੁਰੱਖਿਅਤ ਕਾਰਜ-ਸੀਮਾਵਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਮਾਡਲ ਨੂੰ ਬਿਹਤਰ ਸਥਾਨਕ ਹੱਲ ਲੱਭਣ ਦਿੰਦੀਆਂ ਹਨ.
ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਤਹ ਲਈ ਹੋਰ ਸਖ਼ਤ ਸੁਰੱਖਿਆ ਮਾਡਲ ਵੀ ਲੋੜੀਂਦਾ ਹੈ. ਜਦੋਂ ਏਜੰਟ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕੁਝ ਕਾਰਵਾਈਆਂ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਰਹਿੰਦਾ, ਤਾਂ ਉਹ ਅਸਲ ਵਿੱਚ ਸਿੱਧਾ ਅਸਲੀ ਸਾਫਟਵੇਅਰ ਉੱਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ. ਇਸ ਨਾਲ ਜੋਖਮ ਦਾ ਰੂਪ ਤੁਰੰਤ ਬਦਲ ਜਾਂਦਾ ਹੈ.
ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਸਮੇਂ ਚਾਰ ਚਿੰਤਾਵਾਂ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ:
ਡੇਟਾ ਦਾ ਉਜਾਗਰ ਹੋਣਾ. ਜੇ ਏਜੰਟ ਅਸਲੀ ਇੰਟਰਫੇਸਾਂ ਨਾਲ ਇੰਟਰੈਕਸ਼ਨ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਸ ਨੂੰ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਮਿਲੇਗੀ. ਇਸ ਲਈ ਜਾਣਕਾਰੀ ਲੁਕਾਉਣ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਪ੍ਰਤੀ ਅਨੁਸ਼ਾਸਿਤ ਪਹੁੰਚ ਲਾਜ਼ਮੀ ਹੈ. ਡੇਟਾ ਸਿਰਫ਼ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਲੋੜ ਪੈਣ ਉੱਤੇ ਹੀ ਦਿਖਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਲਾਗਾਂ ਅਤੇ ਟਰੇਸਾਂ ਨੂੰ ਵੀ ਧਿਆਨ ਨਾਲ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਨਿਗਰਾਨੀਯੋਗਤਾ ਹੀ ਸਿਸਟਮ ਦਾ ਸਭ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਹਿੱਸਾ ਨਾ ਬਣ ਜਾਵੇ.
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦਾ ਦਾਇਰਾ. ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਏਜੰਟ ਨੂੰ ਮਨਮਰਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ. ਅਮਲ ਵਿੱਚ ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਹੜੇ ਡੋਮੇਨਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਸਿਸਟਮਾਂ ਨਾਲ ਇੰਟਰੈਕਸ਼ਨ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਉੱਤੇ ਪਾਬੰਦੀਆਂ ਲਾਉਣੀਆਂ. ਇਹ ਪਾਬੰਦੀਆਂ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਰਵਾਇਤੀ ਨਿਯਮਾਂ ਵਜੋਂ ਛੱਡਣ ਦੀ ਬਜਾਏ ਰਨਟਾਈਮ ਪੱਧਰ ਉੱਤੇ ਲਾਗੂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ.
ਵਾਤਾਵਰਨ ਉੱਤੇ ਭਰੋਸਾ. ਆਧੁਨਿਕ ਇੰਟਰਫੇਸਾਂ ਵਿੱਚ ਗੁਮਰਾਹਕੁੰਨ ਜਾਂ ਸਰਗਰਮ ਤੌਰ ਉੱਤੇ ਵਿਰੋਧੀ ਹਦਾਇਤਾਂ, ਸਮੱਗਰੀ ਜਾਂ ਪ੍ਰਵਾਹ ਹੋ ਸਕਦੇ ਹਨ. ਸਫ਼ੇ ਦੀ ਸਮੱਗਰੀ ਰਾਹੀਂ ਪ੍ਰੌੰਪਟ ਇੰਜੈਕਸ਼ਨ ਇੱਕ ਅਸਲੀ ਹਮਲਾ-ਸਤਹ ਹੈ. ਏਜੰਟ ਨੂੰ ਅਣਚਾਹੀਆਂ ਹਦਾਇਤਾਂ ਮੰਨਣ ਤੋਂ ਰੋਕਣ ਲਈ ਸਿਸਟਮ ਨੂੰ ਹਦਾਇਤਾਂ ਦੀ ਸਪਸ਼ਟ ਤਰਜੀਹ-ਲੜੀ, ਪੁਸ਼ਟੀ ਜਾਂਚਾਂ ਅਤੇ ਸਮਾਪਤੀ ਦੀਆਂ ਸ਼ਰਤਾਂ ਚਾਹੀਦੀਆਂ ਹਨ.
ਖ਼ੁਦਮੁਖਤਿਆਰੀ ਦਾ ਪੈਮਾਨਾ. ਸਾਰੀਆਂ ਕਾਰਵਾਈਆਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖ਼ੁਦਮੁਖਤਿਆਰ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ. ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਖ਼ੁਦਮੁਖਤਿਆਰੀ ਨੂੰ ਇੱਕ ਪੈਮਾਨੇ ਵਜੋਂ ਦੇਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ. ਸਿਸਟਮ ਖੋਜ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਢੰਗ ਵਿੱਚ ਬਹੁਤ ਏਜੰਟ-ਕੇਂਦਰਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਕਾਰਵਾਈਆਂ ਦੀਆਂ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਲਈ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਰੱਖ ਸਕਦਾ ਹੈ.
ਮੂਲ ਸਿਧਾਂਤ ਸਿੱਧਾ ਹੈ: ਮਾਡਲ ਨੂੰ ਵਧੇਰੇ ਸ਼ਕਤੀ ਦੇਣ ਲਈ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸਿਸਟਮ ਨੂੰ ਵੀ ਹੋਰ ਮਜ਼ਬੂਤ ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ. ਨੀਤੀ ਤੋਂ ਬਿਨਾਂ ਖ਼ੁਦਮੁਖਤਿਆਰੀ ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ.
ਅਸੀਂ ਇਹ ਪੁੱਛਣਾ ਛੱਡ ਦਿੱਤਾ: ਬ੍ਰਾਊਜ਼ਰ ਦੀਆਂ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਉਪਲਬਧ ਕਰਾਉਣੀਆਂ ਸਹੀ ਹਨ?
ਅਸੀਂ ਇਹ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕੀਤਾ: ਮਾਡਲ ਨੂੰ ਕਾਰਵਾਈਆਂ ਦਾ ਪੂਰਾ ਦਾਇਰਾ ਦੇਣ ਲਈ ਅਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ—ਅਤੇ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਅਜਿਹੀਆਂ ਰਨਟਾਈਮ ਨੀਤੀਆਂ ਕਿਵੇਂ ਬਣਾਈਏ ਜੋ ਇਸ ਨੂੰ ਫਿਰ ਵੀ ਸੁਰੱਖਿਅਤ ਰੱਖਣ?
ਇਹ ਨਵਾਂ ਨਜ਼ਰੀਆ ਤੁਹਾਡੀਆਂ ਤਰਜੀਹਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ. ਕਾਰਵਾਈਆਂ ਦਾ ਵਰਗੀਕਰਨ ਅਤੇ ਰੈਪਰ ਦੀ ਸੰਪੂਰਨਤਾ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ. ਰਨਟਾਈਮ ਨੀਤੀ, ਨਿਗਰਾਨੀਯੋਗਤਾ ਅਤੇ ਹਰ ਪੜਾਅ ਦਾ ਮੁਲਾਂਕਣ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ. ਮਾਡਲ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਇੱਕ-ਦੂਜੇ ਦੇ ਬਦਲ ਨਹੀਂ ਹਨ. ਮਾਡਲਾਂ ਵਿੱਚ ਸੁਧਾਰ ਦੇ ਨਾਲ ਸਿਸਟਮ ਦਾ ਕੰਮ ਘੱਟ ਨਹੀਂ, ਸਗੋਂ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ.
ਪ੍ਰਦਰਸ਼ਨਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ ਏਜੰਟ ਅਕਸਰ ਇਸ ਲਈ ਸਫਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੰਮ ਸੀਮਤ ਅਤੇ ਵਾਤਾਵਰਨ ਸਹਿਯੋਗੀ ਹੁੰਦਾ ਹੈ. ਉਤਪਾਦਨ ਸਿਸਟਮਾਂ ਨੂੰ ਕੁਝ ਵੱਖਰਾ ਚਾਹੀਦਾ ਹੈ: ਸੀਮਤ ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਮਾਪਣਯੋਗ ਵਿਹਾਰ ਅਤੇ ਅਜਿਹਾ ਮੁਲਾਂਕਣ ਜੋ ਸਹੀ ਨਤੀਜੇ ਨੂੰ ਸਿਰਫ਼ ਕਿਸਮਤ ਨਾਲ ਮਿਲੇ ਨਤੀਜੇ ਤੋਂ ਵੱਖ ਕਰ ਸਕੇ.
ਰੈਪਰ ਡਿਜ਼ਾਈਨ ਘੱਟ. ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਵੱਧ.
ਅਸੀਂ ਭਾਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਏਜੰਟਾਂ ਉੱਤੇ ਧਿਆਨ ਦਿੱਤਾ ਹੈ, ਪਰ ਇਹ ਕੰਪਿਊਟਰ ਦੀ ਵਰਤੋਂ ਨੂੰ ਸਿਸਟਮਾਂ ਦੇ ਇੱਕ ਵਿਸ਼ੇ ਵਜੋਂ ਦੇਖਣ ਦੀ ਵਿਆਪਕ ਸੋਚ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ.